Two websites are said to have same origin if both have following in common:
So, sites http://example.com and http://example.com/settings have same origin. But https://example.com:4657 and http://example.com:8080/settings have different origins.
The ‘Same Origin Policy’ restricts how a script loaded from one origin can interact with a resource from another origin. It is an important built-in security mechanism for browsers for isolating potential malicious scripts.
It is the need of Web 2.0 to share resources across origins. Following are some examples:
Apart from the above two scenarios, when one website reads data from another website, it is called as ‘Cross Origin Resource Sharing’ aka CORS.
CORS is a W3 specification that allows cross domain communications from the browser. It works by adding new HTTP Headers that describe the origins that are allowed cross domain information sharing.
In other words, CORS is used to relax the ‘Same Origin Policy’ for legitimate and trusted requests. It is an essential feature of Web 2.0 to support APIs that are exposed via web services to be accessible.
Some noteworthy example of web applications supporting CORS: Google, Youtube, Flickr.
In this demo we are going to use a vulnerable intranet application which has a secret located at ‘secret-cors-3.php’. It has an Admin who accesses it from his local environment. Its URL is: http://127.0.0.1:80/bwapp/.
As it is an intranet application, the attacker cannot interact with it remotely. Our goal as an attacker will be to capture the secret (from a remote internet location) by exploiting CORS vulnerability.
1. The attacker hosts a website containing the malicious script for cross domain interaction.
2. Victim i.e. the Admin of the intranet website visits the attacker’s website. Location http://127.0.0.1:4567
3. Response is received from the attacker’s website containing the following malicious payload:
4. As soon as the web page is loaded, ‘makeRequest’ method is called. The method initiates a cross domain request to capture the secret, to the vulnerable intranet application located at ‘http://127.0.0.1:80/bwapp/secret-cors-1.php’
5. It fetches the response and stores it in the variable ‘secret’.
6. The ‘Access-Control-Allow-Origin’ has value set to *. So, the malicious script now has the payload and it simply issues a GET request to the attacker’s web server. Attacker hosts another web server at location: http://127.0.0.1:7777
7. Meanwhile, attacker monitors the logs of that web server. The payload gets executed and the logs receive the secret.
Another way, an attacker can do this, is by intercepting the request being a man in the middle. But if the attacker has access to the traffic, then capturing cookies and session ID are better options rather than changing the Origin header.
This vulnerability falls under to the category of ‘Security Misconfiguration’ of OWASP Top 10. The HTTP response header ‘Access-Control-Allow-Origin’ is not configured correctly and this creates the issue.
Surely that domain doesn’t match that regex? Whilst a dot is a wildcard, in every flavour I’ve used, it matches a single character, so it will not match com., which would be required given the $ anchor at the end. A better example is presumably https://mailxexample.com.
@Peter, You are correct. I have updated it. Thanks for letting us know that 🙂