Part1 Preface
The CORS cross-domain resource sharing vulnerability is similar to the JSONP hijacking vulnerability, both of which are misconfigured by programmers in solving cross-domain problems. The attacker can use the web application to not strictly verify the Origin header of the user request packet, tricking the victim into visiting the malicious website prepared by the attacker, so as to obtain the victim's sensitive data across domains, including transfer records, transaction records, personal ID number information, order information, etc.
In many penetration test reports in recent years, there are more and more CORS cross-domain resource sharing vulnerabilities. Some friends really can't dig out the loopholes, and occasionally write a report on a CORS cross-domain resource sharing vulnerability, but after careful study of the following issues, they are all ambiguous and unclear.
1. What is a CORS vulnerability?
2. Under what circumstances is a CORS vulnerability a high-risk vulnerability? Under what circumstances are CORS vulnerabilities harmless?
3. How to exploit the CORS vulnerability?
4. Any suggestions for patching the CORS vulnerability?
Many friends think that the Web application returns Access-Control-Allow-Origin: * because there is a loophole. In fact, this judgment is not perfect . In this issue, the author wrote a Java test environment by himself to show you the reproduction process and utilization process of the CORS vulnerability. I believe you can understand it at a glance.
Part2 CORS vulnerability test results
First of all, the final test results are given. The following conclusions are the conclusions given by the self-written Java code to build the environment for testing. Everyone is welcome to criticize and correct. First use burpsuite to capture packets and add Origin: http://www.attacker.com to the http request for testing:
1 If the returned header is in the following situations, it is a high-risk vulnerability. In this case, the vulnerability is best exploited:
Access-Control-Allow-Origin: https://www.attacker.com
Access-Control-Allow-Credentials: true
2 If the returned header is the following, it can also be considered a high-risk vulnerability, but it is more troublesome to exploit:
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
3 If it returns the following, there is no vulnerability, because Null must be lowercase to have a vulnerability:
Access-Control-Allow-Origin: Null
Access-Control-Allow-Credentials: true
4 If it returns the following, it can be considered that there is no vulnerability, because the CORS security mechanism prevents the exploitation of the vulnerability in this case, and low-risk CORS configuration errors can also be written.
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
5 If it returns the following, it can be considered that there is no vulnerability, and you can also write a low-risk CORS configuration error problem.
Access-Control-Allow-Origin: *
Part3 CORS Cross Domain Vulnerability Reappearance
General CORS vulnerability testing process
First, review the conventional CORS vulnerability testing process: grab an HTTP request packet that can return personal sensitive data, add Origin: http://www.xxx.com, and check whether the returned header contains "Access-Control-Allow-Origin: *" and "Access-Control-Allow-Credentials: true". Here is a point, if these two headers exist in the returned packet, then it does not actually have a CORS vulnerability. Next, according to the various return values of Access-Control-Allow-Origin and Access-Control-Allow-Credentials, write Java codes to test whether you can obtain sensitive data, and everyone will understand.
-
Write Java code tests
Next, I wrote two Servlet codes in Java to simulate a Web shopping website, and used JS front-end code to simulate the CORS exploit html page constructed by the attacker.
As shown below, the first is the servlet code of the login interface as follows.
The effect of the code is as follows. After the user enters the user name and password, the shopping website prompts that the login is successful. At this time, the background code has generated a cookie.
Next, the user visits the PersonInfo page, http://192.168.237.1:9999/Servlet/PersonInfo will display the transaction password is 123456.
The sevlet code of PersonInfo corresponding to this page is as follows:
Next, in order to obtain the transaction password of the user of the shopping website, the attacker carefully constructed the following attack.html page and put it on the web server. At this time, the attack URL is http://www.attacker111.com/attack.html . The attacker sends this URL to the victim to browse, and the victim's transaction password will be obtained.
-
Case 1:
First look at the first case. The server returns the following message header. In this case, it is very easy to exploit, so the vulnerability rating is high risk:
Access-Control-Allow-Origin: https://www.attacker.com
Access-Control-Allow-Credentials: true
These two return headers indicate that the application allows any script from any Origin to issue CORS requests to the application. At this time, the programmer's code is written like this:
After the victim visits the URL constructed by the attacker, the sensitive data of the user is successfully obtained.
F12 checks the request sent by the browser and finds that it has a cookie, which successfully bypasses the cross-domain same-origin restriction.
-
Case 2:
The server returns the following message headers. In this case, it is slightly difficult to exploit. The nulls here must be all lowercase, and the vulnerability is still high-risk.
Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
In this case, the value of the application HTTP response header Access-Control-Allow-Origin is always null. The application does not handle when the user specifies any value other than null.
At this time, visit http://192.168.237.199/attack.html and find that the browser prompts a CORS policy error.
Because at this time Origin is not equal to null
Here we need to find a way to make Origin equal to null, so the attacker constructs the following js code:
At this time, it was found that the user's sensitive data could still be obtained successfully.
-
Case 3:
The server returns the following message header. In this case, there is actually no vulnerability. If you have to say that there is a vulnerability, you can negotiate a CORS configuration error. After all, setting it to * itself has problems.
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
The corresponding java code is as follows:
Visiting http://www.attacker111.com/attack.html found that the browser reported an error directly. It seems that this situation is not allowed by the security policy at all.
-
Case 4:
The server returns the following message headers. This will not be demonstrated. It only shows that there is a problem with the CORS configuration, but sensitive data cannot be obtained. The vulnerability rating should be medium or low risk.
Access-Control-Allow-Origin：*
-
Chrome browser test results
Next, I changed to the latest version of Google Chrome browser to test, and found that the same-origin policy was successfully bypassed and a cross-domain request was initiated, but Chrome browser did not bring cookies for the request, so the exploit was limited.
Part4 Patch Recommendations
1. The origin specified in Access-Control-Allow-Origin can only be trusted sites, avoid using Access-Control-Allow-Origin: *, avoid using Access-Control-Allow-Origin: null, otherwise attackers can forge origin requests to achieve cross-domain resource theft.
2. Strictly verify the "Origin" value, and the regular expression for verification must be well-written to avoid bypassing.
3. Reduce the request methods allowed by "Access-Control-Allow-Methods".
4. In addition to properly configuring CORS, web servers should continue to protect sensitive data, such as authentication and session management.