EXPLOITING MISCONFIGURED

CROSS ORIGIN RESOURCE

SHARING

Utkarsh Tiwari
Hi! Hope you guys are doing well. CORS was introduced along with HTML 5. It is a great feature which allows user to
overcome the restrictions placed by Same Origin Policy and make cross-origin HTTP request. But if not configured
properly, it capable of producing disastrous results. Below I have explained different scenarios for exploiting CORS.

Cross Origin Resource Sharing:

Cross-Origin Resource Sharing (CORS) is a mechanism for relaxing the Same Origin Policy to enable communication
between websites via browsers. It is a mechanism that uses additional HTTP headers to tell a browser to let a web
application running at one origin (domain) have permission to access selected resources from a server at a different
origin. A web application makes a Cross-Origin HTTP Request when it requests a resource that has a different origin
(domain, protocol, and port) than its own origin.

Figure 1: Cross Origin Resource Sharing

To read more about CORS, please refer to the below links:

1. https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
2. https://www.keycdn.com/support/cors
3. https://enable-cors.org/
4. https://www.maxcdn.com/one/visual-glossary/cors/
Point to consider while testing CORS Misconfiguration:
1) You can’t disable SOP entirely and expose your site to public by using configuration like:
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Then you’ll get an error in your browser console stating that wildcard (*) in Access-Control-Allow-Origin header
is not allowed when credential flag is true.
2) Whenever you come across any response in which Access-Control-* headers are present but in request no
Origin header is present, then in those cases there is possibility that application is dynamically generating the
Access-Control-* headers in response based on the user supplied values in request.
3) It is important to remember that in scenarios where Origin header and Access-Control-* headers are not
present in the request and response, there also there is possibility that application can dynamically generate
Access-Control-* in response on receiving the Origin header in request.
4) If the server specifies a single origin rather than the * wildcard, then the server should also include Origin in
the Vary response header — to indicate to clients that server responses will differ based on the value of
the Origin request header.

Reasons Behind CORS Misconfiguration:

1) Browser doesn’t support space-separated list of origins (in cases where application wants to trust multiple
origins). Example: Access-Control-Allow-Origin: test.com example.com
2) Can’t use wildcard to trust all subdomains. Example: Access-Control-Allow-Origin: *.example.com

Because of the above reasons/restrictions, many servers programmatically generate the Access-Control-Allow-Origin
header based on the user-supplied Origin value.

Different test cases for testing CORS Misconfiguration:

1) Access-Control-Allow-Origin: *
• Case 1: Add a new origin header in the request with an arbitrary domain in it and see whether it is over-riding
value of Access-Control-Allow-Origin (that is: *) in response or not.

Figure 2: Normal request and response of the application

 Figure 3: Response of application on adding arbitrary Origin header in the request

• Case 2: Check application for instances where application is sending sensitive information in response specific to
the logged in user without validating the session of the user, create a working exploit and report it.

2) Access-Control-Allow-Origin: example.com & Access-Control-Allow-Credentials: true

• Case 1: When server is accepting any origin i.e. origin is not being validated
Change the value of origin header in the request to an arbitrary domain in it and see whether it is over-riding
value of Access-Control-Allow-Origin (that is: example.com) in response or not.

Figure 4: Normal request and response of the application

 Figure 5: Response of application on adding arbitrary Origin header in the request

• Case 2: When regex used on server is accepting all origins which ends with example.com
Change the value of origin header in the request to evilexample.com and see whether it is over-riding value of
Access-Control-Allow-Origin (that is: example.com) in response or not.

Figure 6: Normal request and response of the application

Figure 7: Response of application showing that the regex placed on server for validating origin has been bypassed
• Case 3: When regex used on server is accepting all origins which begins with example.com
Change the value of origin header in the request to example.com.evil.com and see whether it is over-riding
value of Access-Control-Allow-Origin (that is: example.com) in response or not.

Figure 8: Normal request and response of the application

Figure 9: Response of application showing that the regex placed on server for validating origin has been bypassed

3) Access-Control-Allow-Origin: null & Access-Control-Allow-Credentials: true

• Null origin can be achieved by:
a) Sandboxed Iframes
b) If a cross-origin resource redirects to another resource at a new origin, the browser will set the value of the
Origin header to null after redirecting
c) Files on the local file system uses the null origin
d) Some framework allows you to configure which origins you want your application to trust and if you don't want
to configure this variable, programming language will automatically decide to output it as null. So, you tried to
say you don't trust any site but ended up trusting each site.

• Example of CORS exploitation when Access-Control-Allow-Origin: null & Access-Control-Allow-Credentials: true:

Figure 10: Normal request and response of the application

Figure 11: CORS Exploit Code

 Figure 12: Malicious page present in the local system which will initiate the Cross Origin request

Figure 13: Image showing request generated by the malicious page and response received from the server
Figure 14: Image showing malicious page was successfully able to make the Cross Origin request, bypassing the protection placed by the application

Note: The above exploitation was successful because the HTML file containing CORS exploitation code was residing on
the local file system and thus the Origin: Null header was automatically appended in the request.

• References:
a) https://yassineaboukir.com/blog/cors-exploitation-data-exfiltration-when-allowed-origin-is-set-to-null/
b) https://paper.tuisec.win/detail/748995db294e600

4) Scenario when Unencrypted Origin Trusted in CORS

• If protocol is not validated, an attacker who is in the same network as that of victim can tamper the request &
response leading to CORS exploitation. An example of attack scenario is given below:
 Figure 15: Unencrypted Origin Trusted in CORS Exploitation Scenario (PC- @albinowax)

Figure 16: Unencrypted Origin accepted in Access-Control-Allow-Origin header

• Reference: https://www.youtube.com/watch?v=wgkj4ZgxI4c Time: 21:49

Recommendations to fix CORS Misconfiguration:

• Don’t generate Access-Control-Allow-Origin header based on the user-supplied Origin value
• Validate the Origin header with caution
a) Is a valid domain name
b) Ends with your .yourdomain.tld
c) Starts with https://
• Specify Vary: Origin
• Don't trust null!
• Allow multiple origins
• Block reverse mixed content

Advance CORS Exploitation:

To read about advanced CORS exploitation, please refer to the following article: https://www.corben.io/advanced-cors-
techniques/