- From: Tyler Close <tyler.close@gmail.com>
- Date: Wed, 2 Dec 2009 11:52:15 -0800
- To: Joe Gregorio <joe@bitworking.org>
- Cc: "Manger, James H" <James.H.Manger@team.telstra.com>, HTTP Working Group <ietf-http-wg@w3.org>, public-web-security@w3.org
Meta note: This message is CC'd to both ietf-http-wg and the new public-web-security list <http://lists.w3.org/Archives/Public/public-web-security/>. I gather that TPTB want this discussion moved to public-web-security, so please treat this email as the splice in the conversation and remove ietf-http-wg from the CC list of any replies. On Tue, Dec 1, 2009 at 7:00 AM, Joe Gregorio <joe@bitworking.org> wrote: > On Mon, Nov 30, 2009 at 5:52 PM, Manger, James H > <James.H.Manger@team.telstra.com> wrote: >>> The 307 redirect target resource is a good guy. The webbot and the redirect >>> target live behind the same firewall. The evil resource lives outside the >>> firewall. For the protection of the good guy resource, the webbot must >>> enforce the SOP, so that the redirect is not followed. >> >> This actually is covered by the HTTP spec (1.1 and HTTPbis). >> For instance, 8.3.8 307 Temporary Redirect says: >> >> If the 307 status code is received in response to a request method >> that is known to be "safe", as defined in Section 7.1.1, then the >> request MAY be automatically redirected by the user agent without >> confirmation. Otherwise, the user agent MUST NOT automatically >> redirect the request unless it can be confirmed by the user, since >> this might change the conditions under which the request was issued. >> >> [http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-8.3.8] >> >> At the HTTP layer it is not a same-origin issue, but a wider issue with methods that are not "safe". > > I've covered these scenarios in httplib2 with the .folllow_redirects > and .follow_all_redirects options: > > http://httplib2.googlecode.com/hg/doc/html/libhttplib2.html#httplib2.Http.follow_redirects > > Tyler, are you asking for HTTP client libraries to provide something > more comprehensive than that? Yes, to assist implementation of a webbot that obeys the SOP, it would be useful to have a setting to follow only redirects that are allowed by the SOP. For example, see the discussion in: http://lists.w3.org/Archives/Public/ietf-http-wg/2009OctDec/0272.html """ The SOP rule is something like: Don't follow a cross-domain redirect of a PUT request, unless the redirect target has opted out of SOP protection. So, upon seeing the 307 redirect, libcurl would report an error if the origin of the Request-URI does not match the origin of the URL in the Location header; otherwise, the redirect is followed. Until there's a standard way for a resource to opt out of SOP, that's the best that can be done. """ This setting would follow more redirects than your Http.follow_redirects, but fewer than Http.follow_all_redirects. The latter setting follows redirects that violate SOP, and so is dangerous. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Wednesday, 2 December 2009 19:52:49 UTC