Black Box Penetration Testing Guide Cross-site Forging Request CSRF

CSRF ( Cross Site Request Forgery) is a Web application attack that can
It is very harmful to forge a request in the victim's name and send it to the attacked site without the victim's knowledge, thereby performing operations under the protection of rights without authorization.

CSRF key points:

• Target: Users of web applications, not limited to ordinary users;

• Requirement: The forged request is initiated by the user after the vulnerable server is authenticated;

• Cross-site: Use flat to access the attacker server, causing the browser to be controlled to initiate an operation request to the target server, and use flat light method to perceive it.

• Forge: A page preset by an attacker contains parameters that need to be passed to perform a specific operation.

• After authentication: Cross-domain requests will carry cookies from the target website. Before authentication, the target user will have execution rights, and the attack needs to be authenticated before it can succeed.

Note that the CSRFTOKEN parameter may be in the message header or in the message parameter.

Summary of CSRF attack steps

1. Looking for requests that may contain CSRF vulnerabilities

The characteristics of such requests are as follows:

• No CSRF token is set;

• The request performs privileged/critical operations (such as additions, deletions, changes, forms for user password modification functions, forms for personal information updates, user account email or mobile phone binding forms, payments, transfers, etc.);

• Applications rely only on HTTP cookies to track meetings, and all parameters in requests can be predicted;

• An attacker can determine the action to be performed.

2. Convert POST to GET (optional)

Forms are usually submitted using GET and POST, but web applications do not necessarily process GET separately

Requests and POST requests, transforming a POST request into a GET request makes it easier to construct a Payload and easier to conceal at the same time.

3. Construct payload

Construct a specific Payload based on whether the Web application supports GET or POST.

There are two methods to construct Payload:

GET payload :

<img src="”http://pay.SC.weibo.com/aj/service/folowed? uid= your own &amp;" ispage ="1&" t ="0″">

POST payload (perform form submission via js script):

<form id =” demo ´ name = demo actlon =”http://pay.sC.welbo.com/al/service/followed” method =” POST “>

<input type =”text ” name =´”uid” value =”3975359730″/>

<input type = “text” name =”isoage” value =”1″/>

<input type=”text” name =”_T” value =”0″/>

<input type = “submit ” value =”submit” />

Tips: Use burpsuite to intercept the request, send the request to repeater, right click, and select "Generate CSRF Po to quickly generate a POS TU Payload

4. Test POC .

Write the constructed Payload into a complete HTML page, and then use a browser to open it to view the request and response packets.

To test CSRF, you first need to log in to the Web application in advance, establish a session with the server, and then open Payload in a new tab page. If the modification is successful, CSRF exists. If Error is returned, CSRF may not exist, or the application may use CSRF defenses.

5. Bypass defenses

Sometimes it is found that the application system has a token mechanism on the surface to prevent cross-site counterfeiting requests. However, sometimes there will always be some virtual situations.

• Remove the token parameter from the request, and the Web application still executes normally.

• Using predictable CSRF token values, attackers can effectively measure token values in subpages.

For example, after verifying the referer in the request, the Web application determines whether to process the client request by determining whether the referer is a trusted source. In this case, cSRF defense measures need to be analyzed to see if they can be circumvented.

• Bypass referer detection:

You can determine the referer received by the Web application by grabbing the normally accessed request packet.

Referer detection on the server generally uses regular matching to determine whether it is a trusted source.+

Use Fuzzing's method to test a controllable referer that can pass the regular expression check (the referer's verification strategy determines the complexity of the test), and detect whether the referer check can be bypassed.

1. Attack scenario

1. No token mechanism protection

• Description:

  Many application systems have some important operations, such as adding users and roles, transferring money, changing passwords, etc. If these operations do not have a corresponding token mechanism (used to identify whether the person is authorized to operate), unauthorized persons may use the identity of the authorized person to perform involuntary operations by forging requests.

• test method

  First, log in to the application system and find the key operations of the website (depending on the specific business system). Here, we will only take the general user operation as an example. Since most current forms are submitted mainly by the Post method, here is the Post method as an example. After configuring the proxy tool, open the page for adding users and click the button for adding users on the page to submit the request. The proxy tool will intercept the request, which includes the submitted fields and the submitted target URL.

  Suppose the submitted request includes two fields: username (testUserName) and password (testPassWord), and the submitted target URL is http://xXx.XXx.xxx.Xxx/xxx/test.action. Write a test page with the following code:

Finally, put this test page into a browser and run it (you must maintain a session state when running the test page, that is, maintain a login state) to check user management. If the username test n has been successfully added to the application system, it proves that the application system has cross-site forged requests.

2. Invalid token mechanism

• described

  Sometimes it is found that the application system has a token mechanism on the surface to prevent cross-site counterfeiting requests. However, sometimes there will always be some virtual situations.

  Remove the token parameter from the request, and the Web application still executes normally. Using predictable CSRF token values, attackers can effectively page test the token value.

• test method

  Bypass check of request header X CSRF TOKEN

  By intercepting requests in the application system, we found that there was such a field X CSRF TOKEN in the request header. Literally, the request header seemed to be flat to prevent CSRF. By arbitrarily modifying the value of the request header or deleting the request header, and then replayed the request, we found that the request was still executed normally, so it was judged that the token mechanism was invalid

  Bypass referer check

  If you are lucky enough to encounter Sina events, you can get a lucky draw opportunity through forwarding and sharing.

  By analyzing the forwarding interface, the referer is used to verify whether the request source is trustworthy. By analyzing the referer rules, it is found that the referer detection can be bypassed, resulting in CSRF vulnerabilities.

  Bypass method: http://wanwan.sina.com.cn.XX.XX/a.php-

  The name of the city where the attacker was constructed is: wanwan.sina.com.cn.lunull.tk/sina csrf . The php + Payload page is:

Send a website with payload to the user, induce the user to click, and without knowing it, the user sends a message, and the CSRF attack succeeds.

2. Impact

Could lead an attacker to perform unauthorized operations using the identity of a legitimate user.

3. Typical cases

CSRF combines PHP one-sentence Trojan horse to obtain webshel–

The new template function in the background can create a php suffix file. Use the combination of a PHP one-sentence Trojan horse and CSRF to obtain a webshell -after knowing the request to create a file, create a new payload page with the following content:

Construct Payload based on the above flaws and induce logged in administrators to visit the Payload page. That is, use your administrator identity to perform background functions to obtain website webshell

Due to the CSRF vulnerability in the system under test, after inducing the administrator to access the payload page, the POST request was submitted, and a file named test was successfully created in the background. The content of the file was a one-sentence Trojan horse. Then use a Chinese kitchen knife to get a webshell.