12

Cross-site scripting (XSS) is mentioned in the Wikipedia page for CORS. But I don't see how they are related. What's the connection between CORS and XSS?

Simon East
  • 46,575
  • 14
  • 130
  • 124
smwikipedia
  • 52,824
  • 76
  • 267
  • 432
  • 1
    XSS can be used to bypass the restriction of CORS if you leverage a XSS vulnerability to make the requests from an allowed origin. – Gumbo Feb 15 '15 at 15:42
  • @Gumbo I am not sure if I got your point. Say there's a page from site A with XSS issue. I inject a script from B site into A's page. A is in the allowed-site list of site C. So now the injected B script can access content in C. But I think B script still has to follow the CORS standard such as add some necessary headers in order to communicate with C. – smwikipedia Feb 15 '15 at 15:48
  • That’s correct. But the browser will do that for you automatically. – Gumbo Feb 15 '15 at 15:56
  • @SilverlightFox I appreciate it if you add more content. But it may take some time for me to come back to this thread. I am a little busy on something else these days. Sorry for that. And thanks. :) – smwikipedia May 09 '15 at 14:33

3 Answers3

8

XSS is mentioned on the Wikipedia article in relation to JSONP, not CORS.

In JSONP you reference a page containing data you want to include client side in your page like so:

<script src="https://example.com/jsonp.aspx?callback=foo"></script>

You then have a JavaScript function on your page called foo that will be called by the external site (example.com in this case) to pass the data through that your client-side requires.

However, if example.com gets compromised and as you are trusting example.com as a source of scripts an attacker can take your site with it and own the client side code. For example, they could be redirecting visitors to their own site, sending themselves your visitors' cookies or injecting Javascript keyloggers instead of calling your foo function.

With CORS though, if example.com sets the correct headers to allow your site to make AJAX calls to it and retreive the data, then as you should be treating the data as untrused input rather than HTML, it is less likely that your site is neccessarily compromised. It does depend on what the data is - if it is in fact preformatted HTML and you are outputting it as is then then a compromised external site could still affect yours via XSS - however, this is definitely the case with JSONP.

Another point is that if there are any XSS bugs on your site, it would make any CORS restrictions irrelevant. The attacking website would be able to use the XSS vuln to "bypass" the Same Origin Policy at DOM level rather than via XHR. If they needed some information that can only be retrieved from your origin by an AJAX request, they would simply use the XSS attack to inject the script required to do this and send it back to their own domain.

SilverlightFox
  • 28,804
  • 10
  • 63
  • 132
4

https://www.e-systems.tech/documents/20143/30947/main.pdf

Yes, they are extremely connected. I was researching the matter when I came across this unanswered thread. Basically, it should not be a problem for small, simple and public content.

But, as integration through CORS increases in more interactive and complex applications, XSS can be used on a vulnerable system to attack our system. For example a worm propagating itself though XSS can use the vulnerable system just as a delivery mechanism, however, its target can be our system.

On my research I found that CORS will lead to problems with the most common vulnerabilities, especially with hybrid and multilevel attacks; pairs like XSS-CSRF.

Without discussing further all my findings(it was a big paper), if you really want to integrate systems through CORS, vulnerabilities assessments should be made on all partners involved on resource sharing. Depending on the applications domain, if sensitive data is involved, legal concerns will emerge(e.g., who is responsible if a breach occurs.). (the complexity is rarely justifiable).

To use CORS correctly on complex systems, a security professional should be involved. And if the system is to grow with several partners and policies for diverse resources, security should be embedded on the architecture to validate constrains dynamically.

It seems to be clear that for day-to-day use, CORS should be used on limited applications, without sensitive data or with only truly public resources, unless you really trust your partners' security - and implement all the configuration correctly. This is valid if you are building server side architectures, but the other way around is also true, as one will need to trust the content that is to be added on the client side.

Victor
  • 3,070
  • 3
  • 32
  • 51
1

For example: You can inject your js code, that allows you to steal users cookies, into some page (xss). You can do this thanks to CORS.

Hope, that I am not false. Maybe someone will give you better answer.

Vastlik
  • 120
  • 1
  • 8