W3C home > Mailing lists > Public > public-web-security@w3.org > August 2011

Re: lcamtuf on the subtle/deadly problem with CSP

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 30 Aug 2011 22:33:42 -0700
Message-ID: <CAJE5ia85x6MOt5tHZeS3-xRCso8BoXLMuUwDJN+PuiDUG43TpQ@mail.gmail.com>
To: "sird@rckc.at" <sird@rckc.at>
Cc: "Hill, Brad" <bhill@paypal-inc.com>, "public-web-security@w3.org" <public-web-security@w3.org>
It seems like we could let folks specify paths in addition to schemes,
hosts, and ports.

script-src http://example.com/js

would mean you could only load scripts from the "js" directory.  We
should be able to add that in a backwards compatible (but not forwards
compatible) way.  CSP is still behind vendor prefixes in the two
implementations I'm aware of, so making non-forwards compatible
changes is probably still fine.

Adam


On Tue, Aug 30, 2011 at 5:06 PM, sird@rckc.at <sird@rckc.at> wrote:
> Also worth checking:
> http://lists.w3.org/Archives/Public/public-web-security/2011May/0018.html
> Greetings
> -- Eduardo
>
>
>
> On Tue, Aug 30, 2011 at 5:05 PM, sird@rckc.at <sird@rckc.at> wrote:
>>
>> Well, in my case, the only reason I didn't use CSP for protecting gadgets,
>> is the specific case Michal mentioned.. it was just too easy to circumvent
>> on all existing implementation to make it worth the effort of outlining all
>> resources.
>> By the way, in case anyone is interested, the apache module mod_pagespeed
>> has a tool that automatically "outlines" all inline scripts.
>> http://code.google.com/speed/page-speed/docs/filter-js-outline.html
>> This should make deploying CSP more easy.
>> Greetings!!
>> -- Eduardo
>>
>>
>>
>> On Tue, Aug 30, 2011 at 2:22 PM, Hill, Brad <bhill@paypal-inc.com> wrote:
>>>
>>> http://lcamtuf.blogspot.com/2011/08/subtle-deadly-problem-with-csp.html
>>>
>>>
>>>
>>> “The key issue is that the granularity of CSP is limited to SOP origins:
>>> that is, you can permit scripts from http://www1.mysite.com:1234/, or
>>> perhaps from a wildcard such as *.mysite.com - but you can't be any more
>>> precise. I am fairly certain that in a majority of real-world cases, this
>>> will undo many of the apparent benefits of the scheme.”
>>>
>>>
>>>
>>> Basically, Return-Oriented Programming for XSS, or super-DOM-based XSS.
>>> (made easier by patterns like JSONP)
>>>
>>>
>>>
>>> This isn’t a new idea, but I am curious to hear the opinions on the topic
>>> from the readers on this list.  How important is this kind of attack to real
>>> world applications?  Are real world web applications stable and well-defined
>>> enough to be identified in a more granular way?
>>>
>>>
>>>
>>> Brad Hill
>>>
>>> Sr. MTS, Internet Standards and Governance
>>>
>>> PayPal Information Risk Management
>>>
>>> cell: 206.245.7844 / skype: hillbrad
>>>
>>> email: bhill@paypal-inc.com
>>>
>>>
>
>
Received on Wednesday, 31 August 2011 05:34:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 31 August 2011 05:34:47 GMT