Cross Origin Resource Sharing
Hi Guys!
this is my 13th blog in the Web Application Security Penetration Testing blog series. If you haven’t gone through my earlier blogs please navigate to below link and follow me along.
In this blog, I will explain “What is CORS?” “How it works?” and it’s exploitation technique.
CORS (Cross-Origin-Resource-Sharing):
By default, browser implement cross-domain-policy which does not allow a specific domain to make AJAX request to any other domain to access restricted resources. But if we want to do so then need to configure CORS. We can configure CORS using Access-Control-Policy document.
The same-origin policy is a restrictive cross-origin specification that limits the ability for a website to interact with resources outside of the source domain. The same-origin policy was defined many years ago in response to potentially malicious cross-domain interactions, such as one website stealing private data from another. It generally allows a domain to issue requests to other domains, but not to access the responses.
Poorly Implemented CORS Header HTTP Response will be like,
Access-Control-Allow-Origin: *
Access Control Allow Credentials: True
OR
Access-Control-Allow-Origin: Random domain(which is set by changing Origin Header in the request)
Access Control Allow Credentials: True
These headers state that access is allowed from the requesting domain (malicious-website.com) and that the cross-origin requests can include cookies (Access-Control-Allow-Credentials: true) and so will be processed in-session.
Because the application reflects arbitrary origins in the Access-Control-Allow-Origin header, this means that absolutely any domain can access resources from the vulnerable domain. If the response contains any sensitive information such as an API key or CSRF Token. you could retrieve this by placing the following script on your website:
In my pen-testing experience, I have come across one domain which was vulnerable to CORS. To maintain confidentiality let’s call it redacted.com
After changing Origin header to something malicious domain in request, Web server was configuring same malicious domain into server response for Access-Control-Allow-Origin header which makes this website vulnerable to CORS.
Now, Let’s take advantage of above CORS POC to steal some sensitive data from legitimate domain. I have modified CORS POC like below.
Notice as shown below we have received website data from it’s blogs endpoint. Attacker can try different endpoint to steal sensitive data like session cookies or CSRF token, etc.
Impact:
1 Attacker can issue ajax call to extract csrf-token, and with the help of csrf-token attacker can immediately issue new forged csrf request to the legitimate domain.
2 Attacker can extract sensitive information from requested page, like API keys, etc. if requested page consist of sensitive information.
3. A CORS misconfiguration can leave the application at a high-risk of compromise resulting in an impact on the confidentiality and integrity of data by allowing third-party sites to carry out privileged requests through your web site’s authenticated users such as retrieving user setting information or saved payment card data.
4. On the other hand, the risk is low for applications that deal with public data and require that resources are sent to other origins. The configuration could be expected behavior and it would need to be up to the penetration tester to identify the appropriate risk and the organization to understand and mitigate, or accept the risk.
Remediation:
To mitigate the risk of CORS, we always recommend whitelisting your Access-Control-Allow-Origin instead of wildcarding. Using a wildcard prefix such as *.yoursite.com makes it more difficult for the attackers given they would need to find a vulnerability (such as cross-site scripting or cross-site request forgery) to issue the cross-origin request. However, it is frowned upon because it does not provide the critical need-to-know security control. With whitelisting, the scope of your Access-Control-Allow-Origin will be limited to only the sites that deal directly with your primary site or API and exclude any of your sites that do not.
Please do like and comment. Please follow for more reads!
Thanks.
