Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Does CORS and XSS have any connection?

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?

like image 904
smwikipedia Avatar asked Feb 15 '15 15:02

smwikipedia


People also ask

Can XSS Bypass same-origin policy?

And that is where XSS comes into play. It essentially allows bypassing of the SOP, because now an attacker can execute their script from the same origin as the application (eg facebook.com ).

What does CORS defend against?

The CORS mechanism supports secure cross-origin requests and data transfers between browsers and servers. Modern browsers use CORS in APIs such as XMLHttpRequest or Fetch to mitigate the risks of cross-origin HTTP requests.

Is XSS and CSRF same?

What is the difference between XSS and CSRF? Cross-site scripting (or XSS) allows an attacker to execute arbitrary JavaScript within the browser of a victim user. Cross-site request forgery (or CSRF) allows an attacker to induce a victim user to perform actions that they do not intend to.

Is CORS a security risk?

Common vulnerabilities Because CORS is an access control mechanism, it can be misconfigured, thereby enabling an attacker to bypass it and make the client browser act as a proxy between a malicious website and the target web application.


2 Answers

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 retrieve the data, then as you should be treating the data as untrusted input rather than HTML, it is less likely that your site is necessarily 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.

like image 169
SilverlightFox Avatar answered Oct 28 '22 23:10

SilverlightFox


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.

like image 25
Victor Avatar answered Oct 29 '22 00:10

Victor