Cross-Origin Resource Sharing (CORS) Exploit/ HOW TO EXPLOIT CORS
CORS INTRODUCTION
CORS (Cross-Origin Resource Sharing) provides a mechanism to share resources outside the original domain to other domains purposefully but in a controlled manner, If CORS policy is not strongly implemented or enforced it may lead to a cross domain based attacks such as leaking sensitive information to an outside domain such as credentials, API Keys etc.
Description :-
Modern websites use CORS to allow access from subdomains and trusted third parties. Implementation of CORS mistakes can result in exploitable vulnerabilities.
Impact :-
This allowed an attacker to make cross origin requests on behalf of the user as the application did not whitelist the Origin header and had Access-Control-Allow-Credentials: true meaning we could make requests from our attacker’s site .
OWASP Reference No :-
https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A6-Security_Misconfiguration
Recommendation :-
- If a web resource contains sensitive information, the origin should be properly specified in the Access-Control-Allow-Origin header.
- It may seem obvious, but origins specified in the Access-Control-Allow-Origin header should only be sites that are trusted. In particular, dynamically reflecting origins from cross-domain requests without validation is readily exploitable and should be avoided.
- Avoid using the header Access-Control-Allow-Origin: null. Cross-domain resource calls from internal documents and sandboxed requests can specify the null origin. CORS headers should be properly defined in respect of trusted origins for private and public servers.
- Avoid using wildcards in internal networks. Trusting network configuration alone to protect internal resources is not sufficient when internal browsers can access untrusted external domains
- CORS defines browser behaviors and is never a replacement for server-side protection of sensitive data – an attacker can directly forge a request from any trusted origin. Therefore, web servers should continue to apply protections over sensitive data, such as authentication and session management, in addition to properly configured CORS
Proof of Concept :-
1. With valid credential login with this url https://ac1a1f8e1e4cff1880ba1dd2000c000a.web-security-academy.net
2. Now goto this url https://ac1a1f8e1e4cff1880ba1dd2000c000a.web-security-academy.net/accountDetails as shown below :
3. Now refresh the browser >> intercept the request as shown below :
4. Now send the intercepted request to repeater >> add an origin header with malicious url and click on go as shown below :
5. Now make a web page with malicious html code that capture previously logged in user .
6. So with below html code make a web page as shown below :
<html>
<script>
var req = new XMLHttpRequest(); req.onload = reqListener; req.open(‘GET’,’https://ac1a1f8e1e4cff1880ba1dd2000c000a.web-example.net/accountDetails’,true); req.withCredentials = true; req.send(‘{}’); function reqListener() { alert(this.responseText); };
</script>
</html>
As in the below example we have used Google Blogger to create a malicious webpage and publish it online.
7. Now open the url containing above html code as shown below : Sensitive data such as username, email and apikeys can be seen in the below screenshot
Prepared By :- Dhiren Kumar Pradhan
Reviewed By :- Vaibhav Rai
Approved By :- Saurabh Seth