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