HackDig : Dig high-quality web security articles for hacker

OWASP TOP 10: Security Misconfiguration #5 – CORS Vulnerability and Patch

2017-01-07 18:45

What is the meaning of an origin?

Two websites are said to have same origin if both have following in common:

  • Scheme (http, https)
  • Host name (google.com, facebook.com, securelayer7.net)
  • Port number (80, 4567, 7777)

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.

What is cross origin resource sharing?

It is the need of Web 2.0 to share resources across origins. Following are some examples:

  • Cross Origin Writes: A website can POST data to an endpoint of another website.
  • Cross Origin Embedding: A website can refer images from another website using <img src> tag. Also, an iframe using <iframe src> tag can be embedded if the source website allows it.

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.

Two most important CORS Headers:

  • Origin: It is set by browser in every CORS request. Its value is the domain name from which the request originates.
  • Access-Control-Allow-Origin: It is set by server in every CORS response. Depending on its value, the browser decides if the response is allowed or not. It can be set to * (also called the wildcard character) to make resources public (However, this is not a good practice).

A scenario to exploit CORS vulnerability:

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:

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.

The exploitation:

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

 CORS Vulnerability

3. Response is received from the attacker’s website containing the following malicious payload:

CORS Vulnerability

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 ‘’

CORS Misconfiguration


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:

Attackers CORS

7. Meanwhile, attacker monitors the logs of that web server. The payload gets executed and the logs receive the secret.


How to mitigate it?

  • ‘Access-Control-Allow-Origin’ should be never set to * if the resource contains sensitive information.
  • The mitigation is simple and just a proper configuration. Configure the Access-Control-Allow-Origin header to allow requests only from the domains that you trust. For e.g.: Access-Control-Allow-Origin: saurabh.com The below image illustrates that the CORS attack does NOT get executed when the server is configured with correct ‘Access-Control-Allow-Origin’ instead of a ‘Wildcard’ character.

CORS Patch

  • Client should not trust the received content without sanitization because that will result in client side code execution. For example: If website abc.com trusts and fetches cross domain data from example.com. example.com has a malicious intent and starts sering malicious javascript to abc.com, then abc.com can protect its users from cross site scripting by sanitizing the received data and then presenting it to its users.

OWASP category for CORS Vulnerability:

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.




The post OWASP TOP 10: Security Misconfiguration #5 – CORS Vulnerability and Patch appeared first on SecureLayer7.

Source: /hctap-ytilibarenluv-sroc-5-noitarugifnocsim-ytiruces-01-pot-psawo/ten.7reyaleruces.golb

“OWASP TOP 10: Security Misconfiguration #5 – CORS Vulnerability and Patch”0 Comments

Submit A Comment



Blog :

Verification Code:


Share high-quality web security related articles with you:)


Tag Cloud