Re: CORS security hole?

On Mon, Jul 16, 2012 at 11:22 PM, Henry Story <henry.story@bblfish.net> wrote:
>
> On 17 Jul 2012, at 08:10, Adam Barth wrote:
>
>
>
> On Mon, Jul 16, 2012 at 11:01 PM, Henry Story <henry.story@bblfish.net>
> wrote:
>>
>> I first posted this to public-webapps, and was then told the security
>> discussions were taking
>> place on public-webappsec, so I reposted there.
>>
>> On 17 Jul 2012, at 00:39, Adam Barth wrote:
>>
>> As I wrote when you first posted this to public-webapps:
>>
>> [[
>> I'm not sure I fully understand the issue you're worried about, but if I
>> understand it correctly, you've installed an HTTP proxy that forcibly adds
>> CORS headers to every response.  Such a proxy will indeed lead to security
>> problems.  You and I can debate whether the blame for those security problem
>> lies with the proxy or with CORS, but I think reasonable people would agree
>> that forcibly injecting a security policy into the responses of other
>> servers without their consent is a bad practice.
>> ]]
>>
>>
>> Hmm, I think I just understood where the mistake in my reasoning is: When
>> making a request on the CORS proxy (
>> http://proxy.com/cors?url=http://bank.com/joe/statement on a resource
>> intended for bank.com, the browser will not send the bank.com credentials to
>> the proxy - since bank.com and proxy.com are different domains.  So the
>> attack I was imagining won't work, since the proxy won't just be able to use
>> those to pass itself for the browser user.
>>
>> Installing an HTTP proxy locally would of course be a trojan horse attack,
>> and then all bets are off.
>>
>> The danger might rather be the inverse, namely that if a CORS proxy is
>> hosted by a web site used by the browser user for other authenticated
>> purposes ( say a social web server running on a freedom box ) that the
>> browser pass the authentication information to the proxy in the form of
>> cookies, and that this proxy then pass those to any site the initial script
>> was connected to.
>>
>> Here using only client side certificate authentication helps, as that is
>> an authentication mechanism that cannot be forged or accidentally passed on.
>>
>> ---
>>
>> Having said that, are there plans to get to a point where JavaScript
>> agents could be identified in a more fine grained manner?
>
>
> No.
>
>>
>> Cryptographically perhaps with a WebID?
>
>
> That's unlikely to happen soon.
>
>> Then the Origin header could be a WebID and it would be possible for a
>> user to specify in his foaf profile his trust for a number of such agents?
>> But perhaps I should start that discussion in another thread....
>
>
> I'd recommend getting some implementor interest in your proposals before
> starting such a thread.  A standard without implementations is like a fish
> without water.
>
>
> Ok, I don't really have a browser to hack on. On the other hand a few of us
> are working on building a CORS
> proxy at the read-write-web community group to enable javascript linked data
> agents to build up in the browser views of data distributed on the web.
> There may be some interesting results this brings up that we can discuss at
> TPAC in Lyon... :-)
>

Building a CORS proxy for any reason other than to prototype something
sounds (at first blush) like a bad idea; as Adam says, you're
basically changing the security policies the web is supposed to be
using. It seems like if you're having to do this you're solving the
wrong problem, and maybe there's something else that should be
changed?

-- Dirk

Received on Tuesday, 17 July 2012 19:33:42 UTC