Re: lcamtuf on the subtle/deadly problem with CSP

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****
>>
>> ** **
>>
>
>