Bug 11119

Summary: Some HTTP redirects that are required to force user interaction, do not
Product: WebKit Reporter: Mark Rowe (bdash) <mrowe>
Component: Page LoadingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: ahanakothari1991, annevk, ap, grahamperrin, mnot
Priority: P2    
Version: 420+   
Hardware: Mac   
OS: OS X 10.4   
URL: http://www.mnot.net/javascript/xmlhttprequest/#301GET

Description Mark Rowe (bdash) 2006-10-02 04:53:32 PDT
From the URL:

"Are redirects automated appropriately?
Implementations that handle redirects automatically are required by HTTP to force user intervention before some combinations of request method and redirect status code are handled automatically. Those that fail these test do not do so, and therefore may cause dangerous requests to be made.

For example, if Alice's browser that doesn't check with her before redirecting a POST to another server, this could be exploited to change her data on a third-party server (e.g., her bank) without her knowledge."

Section 10.3 of RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3) provides the specification for this behaviour.

Output from this section in ToT WebKit is as follows:

GET to a 301 Permanent Redirect:  success
POST to a 301 Permanent Redirect:  fail (wrong behaviour)
PUT to a 301 Permanent Redirect:  fail (wrong behaviour)
DELETE to a 301 Permanent Redirect:  fail (wrong behaviour)
GET to a 302 Found:  success
POST to a 302 Found:  fail (wrong behaviour)
PUT to a 302 Found:  fail (wrong behaviour)
DELETE to a 302 Found:  fail (wrong behaviour)
GET to a 303 See Other:  success
POST to a 303 See Other:  success
PUT to a 303 See Other:  success
DELETE to a 303 See Other:  success
GET to a 307 Temporary Redirect:  success
POST to a 307 Temporary Redirect:  fail (wrong behaviour)
PUT to a 307 Temporary Redirect:  fail (wrong behaviour)
DELETE to a 307 Temporary Redirect:  fail (wrong behaviour)

All tests marked as failing with wrong behaviour are required to force user interaction before proceeding with the redirect, but do not do so.
Comment 1 Alexey Proskuryakov 2006-10-02 22:31:11 PDT
As long as we change the method to GET (bug 11118), we do not need to ask for confirmation AFAICT.

Also, I am not sure if I understand what the XMLHttpRequest spec says on the subject:
----------------------------------
If the response is an HTTP redirect (status code 301, 302, 303 or 307), then it must be transparently followed (unless it violates security, infinite loop precautions or the scheme isn't supported). Note that HTTP ([RFC2616]) places requirements on user agents regarding the preservation of the request method during redirects, and also requires users to be notified of certain kinds of automatic redirections.
----------------------------------

The MUST requirement is to follow redirects transparently, and the note might mean that XHR requests do not fully obey RFC2616 (which seems to be the case anyway, according to <http://lists.w3.org/Archives/Public/public-webapi/2006Sep/0002.html>). Or maybe the MUST part refers to the fact that redirection appears transparent to the XMLHttpRequest object, not to the user?
Comment 2 Anne van Kesteren 2017-03-13 01:15:57 PDT
FWIW, this requirement is nonsense, since we don't prompt the user for a non-redirected POST either. I recommend implementing the required semantics, but not do any prompting. That's what other user agents implement.