Re: FW: Java Script Client

Tony Arcieri <[email protected]>
Newsgroups gmane.comp.capabilities.general
Message-ID <CAHOTMVKSzA1sDuc77kTxTwxQRAdznxTCexitBZiLwgT6a7-CyQ@mail.gmail.com>
On Tue, May 27, 2014 at 10:05 AM, Stiegler, Marc <[email protected]>wrote:

>  As nearly as I can tell, the main goal of the Content Security Policy
> meta tag is to prevent XSS. But they carefully, and correctly, assert that
> it does not actually fully prevent XSS. And the caveats  about what it does
> and does not prevent are so complicated that the only safe policy is to
> conduct rigorous XSS hygiene on the content you display anyway. I.e., you
> should turn it on, but then you must assume that it does not work.
>

The real problems with CSP are mostly browser errata and low adoption. If
you configure CSP stringently enough (i.e. default-src 'self') and the
browser implementation does what it promises, inline scripts are not
allowed to run at all. This mitigates a whole class of attacks.

It's true it's not a silver bullet. If you can inject a script tag into the
page, and dynamically control the content of a resource on the same origin
such that the browser will interpret it as JavaScript, you can potentially
pull off reflective XSS that way.

However, it scopes the attack to the same origin. With default-src 'self',
the browser will refuse to load *any* assets on a separate origin (scripts,
images, video, etc), and will not execute inline scripts. IMO this
substantially reduces attack surface versus a non-CSP scenario, and also
complicates exfiltration of data from the page.

-- 
Tony Arcieri

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.