W3C home > Mailing lists > Public > public-web-security@w3.org > December 2009

Re: HTTPbis and the Same Origin Policy

From: Tyler Close <tyler.close@gmail.com>
Date: Thu, 3 Dec 2009 12:10:39 -0800
Message-ID: <5691356f0912031210r3763f826v96a11f77bff6efe6@mail.gmail.com>
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.


"Waterken News: Capability security on the Web"
Received on Thursday, 3 December 2009 20:11:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:23 UTC