Security/Reviews/XHRnonpost: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| Line 10: | Line 10: | ||
=== Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) === | === Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) === | ||
Notes for security review of HTTP redirect behavior changes | Notes for security review of HTTP redirect behavior changes | ||
julian.reschke@gmx.de, | julian.reschke@gmx.de, 2012-01-06 | ||
1) When an HTTP request is redirected, what is the right HTTP method to use for the redirected request? | 1) When an HTTP request is redirected, what is the right HTTP method to use for the redirected request? | ||
| Line 36: | Line 36: | ||
** downside to 3) is that XHR-using script authors (or library authors) might not be smart about it. | ** downside to 3) is that XHR-using script authors (or library authors) might not be smart about it. | ||
* on the topic of redirect prompting in IE -- tested with <http://www.mnot.net/javascript/xmlhttprequest/>; it does not appear to prompt for unsafe methods | * on the topic of redirect prompting in IE -- tested with <http://www.mnot.net/javascript/xmlhttprequest/>; it does not appear to prompt for unsafe methods | ||
4) Status Code 308 | |||
* Bug: <https://bugzilla.mozilla.org/show_bug.cgi?id=714302> | |||
* Spec: <http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-latest.html> | |||
* 308 works the same as 307, except that it signals a permanent condition; Firefox doesn't care about this distinction, so 308 does exactly what 307 does | |||
* Experimental spec, planning to do an IETF Last Call soon | |||
* Looking for feedback on the best approach to introduce this (wait until IETF LC, IETF Publication Requested, IESG Approval, RFC publication?) | |||
=== What solutions/approaches were considered other than the proposed solution? === | === What solutions/approaches were considered other than the proposed solution? === | ||
Latest revision as of 17:10, 6 January 2012
Items to be reviewed
- XHR rewrites non-POST methods upon 301/302 redirects
- add support for HTTP status code 308
Introduce Feature (5-10 minutes) [can be answered ahead of time to save meeting time]
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
Notes for security review of HTTP redirect behavior changes julian.reschke@gmx.de, 2012-01-06
1) When an HTTP request is redirected, what is the right HTTP method to use for the redirected request?
- Refs: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/160>, <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.3xx>
- Bug: <https://bugzilla.mozilla.org/show_bug.cgi?id=598304>
- See also: <https://code.google.com/p/chromium/issues/detail?id=56373>, <https://bugs.webkit.org/show_bug.cgi?id=46183>, <https://blogs.msdn.com/b/ieinternals/archive/2011/08/19/understanding-the-impact-of-redirect-response-status-codes-on-http-methods-like-head-get-post-and-delete.aspx>
- RFC 2616 was clear for 307 (same method) and 303 (retrieval, so GET unless you started with HEAD).
- RFC 2616 was almost clear for 301/302 (as 307).
- Whether 301/302 should be like 303 or 307 is an age-old debate, going back into pre HTTP/1.1 time (1997).
- Many web server respond to POSTs with 301/302 and assume they'll see a GET.
- Other HTTP servers expect the opposite, such when redirecting to a WebDAV collection URI.
- HTTPbis changed to *allow* the rewrite for POST, but no other method
- So HTML forms aren't affected (until methods != GET/POST will be allowed).
- What's affected is XHR, where silently rewriting the method almost never is the right thing to do (think PROPFIND).
- IE has been preserving the method unless it was POST since the beginnings of XHR; Chrome 17 (now in beta) does this as well
- Note that not following the redirect automatically and putting the script calling XHR in charge would be another option
2) When a redirect happens, when should the UA prompt?
- https://bugzilla.mozilla.org/show_bug.cgi?id=676059 (fixed)
- (Julian Reschke, 2011-10-27: resolved for Firefox 10 as of 2011-10-15)
3) Prompting in general
- Bug: <https://bugzilla.mozilla.org/show_bug.cgi?id=677754>
- Some people say the UA should not prompt at all.
- If XHR does not prompt, it should return the 3xx to the caller letting it decide how to proceed.
- I believe 3) is important, but can be discussed and changed at a later point.
- downside to 3) is that XHR-using script authors (or library authors) might not be smart about it.
- on the topic of redirect prompting in IE -- tested with <http://www.mnot.net/javascript/xmlhttprequest/>; it does not appear to prompt for unsafe methods
4) Status Code 308
- Bug: <https://bugzilla.mozilla.org/show_bug.cgi?id=714302>
- Spec: <http://greenbytes.de/tech/webdav/draft-reschke-http-status-308-latest.html>
- 308 works the same as 307, except that it signals a permanent condition; Firefox doesn't care about this distinction, so 308 does exactly what 307 does
- Experimental spec, planning to do an IETF Last Call soon
- Looking for feedback on the best approach to introduce this (wait until IETF LC, IETF Publication Requested, IESG Approval, RFC publication?)
What solutions/approaches were considered other than the proposed solution?
- closer adherence to standard
Why was this solution chosen?
- closer adherence to the revised HTTP standard
Any security threats already considered in the design and why?
- lots of stuff around redirects has been done before
Threat Brainstorming (30-40 minutes)
- relevant to 1) and 2) please see also https://bugzilla.mozilla.org/show_bug.cgi?id=573873
- which stopped plugins following a cross domain 307 altogether. jonas asks that whatever decisions we make avoid reintroducing this problem.
- (jre: whatever the solution for 307 is should be the same for 301/302...)
Conclusions / Action Items (10-20 minutes)
- [jonas / someone] 301/302 could go three ways: switch to IE behavior, stick with "historical" rewriting assuming dumb servers, or don't follow the redirect at all (return the 30x to script?)
- needs to be done with other browser vendors
- [mozsec / chrome(?)] survey of redirectors in-the-wild -- are they sane or not? (re: 301/302 non-GET/POST methods)
- [dveditz] bug for redirect intentions for a moved resource
Historical Information
Items to be reviewed
- Make redirect prompting depend on HTTP-safeness of method, not presence of request body
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
2) When a redirect happens, when should the UA prompt?
- Refs: <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest.html#status.3xx>
- Bug: <https://bugzilla.mozilla.org/show_bug.cgi?id=676059>
- Firefox makes it depend on the presence of a request body. This is fine for GET and POST.
- Specification says it should depend on safeness of method, so you can follow a PROPFIND despite it having a request body, but should not for a DELETE.
- Note that resolving 1) will cause the redirected method to be != GET in more cases, so this is important.
- 307 always preserved the method, so the problem needs to be fixed independently of 1).
- (Julian Reschke, 2011-10-27: resolved for Firefox 10 as of 2011-10-15)