- From: Tyler Close <tyler.close@gmail.com>
- Date: Thu, 3 Dec 2009 12:10:39 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Adam Barth <w3c@adambarth.com>, Martin J. Dürst <duerst@it.aoyama.ac.jp>, Julian Reschke <julian.reschke@gmx.de>, public-web-security@w3.org
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.html
Received on Thursday, 3 December 2009 20:11:20 UTC