On Thu, Dec 3, 2009 at 10:37 AM, Maciej Stachowiak <mjs@apple.com> wrote: > Do you see an actual flaw in my reasoning as applied to the command-line > tool in question? Sending a POST request with Content-Type application/xml using a webbot is a likely thing to do and the redirect attack would not be prevented by either of the mitigations you listed. > I think it is correct that blindly following redirects even in a relatively > low-level client may expose resources behind firewalls to unexpected > requests, and that this may pose security risk. Great, that's the door I was trying to open: even low-level HTTP clients need some SOP knowledge. > I'm not sure there is risk > beyond that unless the client executes script that it receives, processes > HTML, or otherwise behaves in a browser-like way. We should probably figure > out the scope of the risk and a recommendation for mitigating it before > debating whose job it is to document it. I suspect there's also a need to specify the SOP restrictions around access to responses, but the attack scenario is more complicated to explain. I think it can be done without involving HTML or scripting. All you need is a multi-request scenario in which the client sends a request that includes data from a previous GET response. The attack resource redirects the GET request to a resource behind the firewall. Anyways, we can come back to that later if we get the ball rolling with the simpler redirect of a POST/PUT/DELETE scenario. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.htmlReceived on Thursday, 3 December 2009 20:11:20 UTC
This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:17 UTC