WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
11119
Some HTTP redirects that are required to force user interaction, do not
https://bugs.webkit.org/show_bug.cgi?id=11119
Summary
Some HTTP redirects that are required to force user interaction, do not
Mark Rowe (bdash)
Reported
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
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?
Anne van Kesteren
Comment 2
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug