Re: lcamtuf on the subtle/deadly problem with CSP

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