Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How is CORS safer than no cross domain restrictions? It seems to me that it can be used maliciously

I've done a bit of reading on working around the cross domain policy, and am now aware of two ways that will work for me, but I am struggling to understand how CORS is safer than having no cross domain restriction at all.

As I understand it, the cross domain restriction was put in place because theoretically a malicious script could be inserted into a page that the user is viewing which could cause the sending of data to a server that is not associated (i.e. not the same domain) to site that the user has specifically loaded.

Now with the CORS feature, it seems like this can be worked around by the malicious guys because it's the malicous server itself that is allowed to authorises the cross domain request. So if a malicious script decides to sending details to a malicious server that has Access-Control-Allow-Origin: * set, it can now recieve that data.

I'm sure I've misunderstood something here, can anybody clarify?

like image 623
Grezzo Avatar asked May 31 '12 16:05

Grezzo


People also ask

Is CORS actually secure?

If implemented badly, CORS can lead to major security risk like leaking of API keys, other users data or even much more. A very great example of security risk of CORS misconfiguration is this.

Why is CORS helpful?

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.

Are different ports considered cross domain?

Websites that have the combination of the same scheme, hostname, and port are considered "same-origin". Everything else is considered "cross-origin".


2 Answers

I think @dystroy has a point there, but not all of what I was looking for. This answer also helped. https://stackoverflow.com/a/4851237/830431

I now understand that it's nothing to do with prevention of sending data, and more to do with preventing unauthorised actions.

For example: A site that you are logged in to (e.g. social network or bank) may have a trusted session open with your browser. If you then visit a dodgy site, they will not be able to perform a cross site scripting attack using the sites that you are logged in to (e.g. post spammy status updates, get personal details, or transfer money from your account) because of the cross domain restriction policy. The only way they would be able to perform that cross site scripting attack would be if the browser didn't have the cross site restriction enabled, or if the social network or bank had implemented CORS to include requests from untrusted domains.

If a site (e.g. bank or social network) decides to implement CORS, then they should be sure that it can't result in unauthorised actions or unauthorised data being retrieved, but something like a news website content API or yahoo pipes has nothing to lose by enabling CORS on *

like image 95
Grezzo Avatar answered Nov 10 '22 01:11

Grezzo


You may set more precise origin filter than "*".

If you decide to open your specific page to be included in another page, it means you'll handle the consequences.

But the main problem cannot be that a server can receive strange data : that's nothing new : everything that is received by a server is suspect. The protection is mainly for the user which cannot be abused by an abnormal composition of sources (the englobing one being able to read the englobed data, for example). So if you allow all origins for a page, don't put inside data that you want to share only with your user.

like image 20
Denys Séguret Avatar answered Nov 10 '22 00:11

Denys Séguret