CORS Cross Origin Resource Sharing Vulnerability on Live Website

 

 

 

 

What is CORS? 

Cross-Origin Resource Sharing

W3C working draft that defines how the browser and server must communicate when accessing sources across origins. CORS Cross Origin Resource Sharing Vulnerability on Live Website

Implemented via HTTP headers that servers set and browsers enforce.

 

Can be categoriezed into 

 
 - Simple Requests
 - Requests that need a Prelight
 

Working Process

credit for this image hacktify

Three Important Cases for CORS

 

We are going to see important cases for identify a CORS vulnerability. This is the best which is the best case for this vulnerability.

 

 

 

As you can see under the left side it is the request and right side it is the response if we try to add our header into the request and header is origin And let say we type any.com which is attacker.com and if this attacker.com get reflected into the response in this two headers. Access-Control-Allow-Origin attacker.com and Access-Control-Allow-Credentials true then this is vulnerable which is the best test best case for us.

so we have understood the first and the best test case is that whenever we try to supply attacker.com into the origin into the request if we get the attackr.com as it is into the response then it is the best test case for the attacks.

So now let's see the second best test case for for our exploitation.In the request it is attacker.com. In the origin header and in the response if it shows something like null in Access-Control-Allow-Origin and Access-Control-Allow-Credentials if we seen True then also it is the best test case for our attack. So I hope you guys understood the first and second test case.

 
In the first test case we got attacker.com as it is by passing it in the request we got as into the request and in the second test case we passed at the attacker.com and in the response Null. Which also means it is exploitable. 

 

               
                                                

So, let's see the last test case which is the case 3 which is a bad implementation but not exploitable test case we cannot exploit this test case. so, in the request if attacker.com is passed into a header that is origin and in the response if we get * (star) in access-control-allow-origin if we get a * (star) then it is not exploitable this test case is not exploitable. we cannot exploit this so to conclude the first to test cases we can exploit in which we are able to see a reflection of the origin into the response that is a attacker.com that is the first test case in the second test case if you are able to see Null then it is also exploitable but if you're getting a * (star) into the response it is not acceptable I hope you guys understood this and now it is the practical time let see the practical for this.

Practical

I will get a request into my burp suite after getting the request i am going to this request to the repeater so that i can use this request again and again. Now in near what i am doing to do is!! I am going to add a new header and header is Origin as we saw into our test cases. after adding here Origin: https://hackingtruth.in and i am going hit go.

If you look closely in the response tab there is something which is generated, here is link and the link which is i am getting one more End-point zinghr.com (/wp-json/).

What if try to send a request to add this point GET /wp-json/ HTTP/1.1 with these Origin.

So this time when i did go. Vola!! as you can see this time the zinghr.com server has trusted this attacker server that is hackingtruth.in and is ready to exchange the data between in the server. So this website is vulnerable with CORS.



Access-Control-Allow-Origin: https://hackingtruth.in
Access-control-allow-origin: True
 
which is reflected.

Manually

Lets do this how to manualy exploit this issue with curl command and those who don't know what is curl basically curl is a simple utility which is responsible to sending the request to any target and getting a response.

curl "https://zinghr.com/wp-json/" -I 

 

-I - For header that i only want to see response header instead of whole page source. There is something which is generated, here is link and the link which is i am getting one more End-point zinghr.com (/wp-json/)

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$ curl "https://zinghr.com/wp-json/" -I                     
HTTP/2 200 
date: Sun, 04 Jul 2021 19:13:49 GMT
server: Apache
x-powered-by: PHP/7.3.26
x-robots-tag: noindex
link: <https://www.zinghr.com/wp-json/>; rel="https://api.w.org/"
x-content-type-options: nosniff
access-control-expose-headers: X-WP-Total, X-WP-TotalPages, Link
access-control-allow-headers: Authorization, X-WP-Nonce, Content-Disposition, Content-MD5, Content-Type
allow: GET
vary: User-Agent
content-type: application/json; charset=UTF-8

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$ 

 

link: <https://www.zinghr.com/wp-json/>; rel="https://api.w.org/"

 

So, now we add a new header called origin and now i am going to hit enter and check for verify this origin is trusted by zinghr.com server or not? But if this is trusted then it back reflected into the response header.

curl "https://zinghr.com/wp-json/" -I -H Origin: https://hackingtruth.in

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$ curl "https://zinghr.com/wp-json/" -I -H Origin:https://hackingtruth.in
HTTP/2 200 
date: Sun, 04 Jul 2021 19:19:44 GMT
server: Apache
x-powered-by: PHP/7.3.26
x-robots-tag: noindex
link: <https://www.zinghr.com/wp-json/>; rel="https://api.w.org/"
x-content-type-options: nosniff
access-control-expose-headers: X-WP-Total, X-WP-TotalPages, Link
access-control-allow-headers: Authorization, X-WP-Nonce, Content-Disposition, Content-MD5, Content-Type
allow: GET
access-control-allow-origin: https://hackingtruth.in
access-control-allow-methods: OPTIONS, GET, POST, PUT, PATCH, DELETE
access-control-allow-credentials: true
vary: Origin,User-Agent
content-type: application/json; charset=UTF-8

┌──(hackerboy㉿KumarAtulJaiswal)-[~]
└─$ 

 

Access-Control-Allow-Origin: https://hackingtruth.in
Access-control-allow-origin: True
 
which is reflected.


As you can see our best test case that is the first test case is been satisfied over here and we are able to get our attacker.com reflected into the response. so i hope you guys understood. How to find this vulnerability using burp suite as well as curl.

Provided by HackerOne CORS Report

CORS Mitigation

1) SOP! Same Origin Policy
2) Do not trust any aribitary origin and communication with it!




what are the mitigations for CORS.

1) So the first and the best mitigations for CORS is SOP the same origin policy. so this policy means this policy means that the web site or the web application should not transfer any kind of data to any other web application so it should only communicate and transfer the data with the same origin for same website.


2) Do not trust any arbitrary origin and communicate with that if any web application is getting any origin header as a request that should not trust that arbitrary header and give out sensitive information basically whenever attacker tries to do a reflective origin based CORS the server should discard that I should not trusted and should not give out the response to that server. Secondly if a suffix or prefix based cause exploitation is performed the server should do proper validation not just limited to checking the hostname into the origin we have already seen if the server is misconfigured and just check for the name into the origin header and takes decisions based on that which is dangerous can lead to CORS exploitation. So do not trust any arbitrary origin and communicate with it is the best mitigation for CORS. so I hope you understood the mitigation for CORS.

Provided by HackerOne CORS Report

 

Disclaimer

 

All tutorials are for informational and educational purposes only and have been made using our own routers, servers, websites and other vulnerable free resources. we do not contain any illegal activity. We believe that ethical hacking, information security and cyber security should be familiar subjects to anyone using digital information and computers. Hacking Truth is against misuse of the information and we strongly suggest against it. Please regard the word hacking as ethical hacking or penetration testing every time this word is used. We do not promote, encourage, support or excite any illegal activity or hacking.



  - Hacking Truth by Kumar Atul Jaiswal