Yes, CORS does not help protect against CSP, allthough it may reduce self-introduced XSS to bypass SOP. CSP on the other hand, will block many XSS attacks as long as unsafe-inline and unsafe-eval is not used. Erlend From: Paul Johnston Sent: 11.11.2012 01:00 To: websecurity@lists.webappsec.org Subject: Re: [WEB SECURITY] Wanted: HTML5 Web Security Researcher Hi, I haven't played around with CORS, but just from reading the article and generally, I don't agree with your conclusions. > 80% of sites using CORS explicitly allow all (the "promiscuous asterisk" > that I first encountered with Banyan Vines email). If, prior to CORS* the > sites were using anonymous server-side proxy (or other technique?) to allow > similar access, then net impact is 0. If pre-CORS* the sites were not > explicitly defining any privileges, then the sites were governed by > same-origin and therefore the net impact is risk increasing. The article mentions that with a wildcard, a request can be sent with cookies, but JavaScript can't read the response. I think we only need to really worry about requests with cookies - without this (and knowing the URL) the attacker could just make that request themselves directly (although this may be a way to bypass IP based restrictions). The status quo, is that you can send such a request anyway, using something like an image tag or a form target - but the cross origin model prevents reading the response. So I think the risk for these sites is quite minor. Probably biggest risk is that some clients may incorrectly implement CORS, and having this header exposes you to related bugs. > 20% of sites using CORS explicitly define a single origin (presumably their > own). If these sites were susceptible to XSS pre-CORS (a good assumption) > then the impact is risk reducing. If the sites were not susceptible to XSS > then the impact is 0. If the site is susceptible to XSS without CORS, then I don't think having a CORS header greatly reduces the risk. For a simple XSS, like getting a user to click a link to http://vuln/vuln?id=<script>alert(1)</script> - CORS will make no difference. I think CORS is not intended as a security mechanism, more as new functionality to allow cross-domain requests. It seems to me to be designed to do this reasonably securely - although looking for implementation bugs would be interesting. There is the more general trust issue of allowing an external site to access response bodies with cookies, but that's not greatly different to existing trust issues around JSONP and <script> tags with external links. Bottom line is it gives the administrator the option to trust something external - and it's down to them to make sure the external party really is trustworthy. Paul -- Pentest - When a tick in the box is not enough Paul Johnston - IT Security Consultant / Tiger SST Pentest Limited - ISO 9001 (cert 107029) / ISO 27001 (cert 558982) Office: +44 (0) 161 233 0100 Mobile: +44 (0) 7817 219 072 Email policy: http://www.pentest.co.uk/legal.shtml#emailpolicy Registered Number: 4217114 England & Wales Registered Office: 26a The Downs, Altrincham, Cheshire, WA14 2PU, UK _______________________________________________ The Web Security Mailing List WebSecurity RSS Feed http://www.webappsec.org/rss/websecurity.rss Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA WASC on Twitter http://twitter.com/wascupdates websecurity@lists.webappsec.org http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org