Re: FW: Java Script Client
"Stiegler, Marc" <[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <63601DC9100AAC48812C1985727F34485C9065B5@G9W0727.americas.hpqcorp.net> |
Please note, it seems you did not actually disagree with what I said, namely, “turn it on, and then assume it does not work”. You still have to do all the hygiene on all the display operations for dynamic data anyway. It will only provide better security if it does not lure people into becoming lax about their hygiene. Having said that, since you have studied this much more carefully than I, and since I would like to use CSP as a backup to strict hygiene (since I am an imperfect implementer of strict hygiene, and I have no one to review what I write), could you lay out what you would consider to be a correct CSP tag character by character, so I can incorporate it in all my pages? --marcs From: [email protected] [mailto:[email protected]] On Behalf Of Tony Arcieri Sent: Tuesday, May 27, 2014 11:17 AM To: General discussions concerning capability systems. Subject: Re: [cap-talk] FW: Java Script Client On Tue, May 27, 2014 at 10:05 AM, Stiegler, Marc <[email protected]<mailto:[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