DVWA series of CSRF Vulnerability analysis

Let's take a look at the low level of the CSRF source code:

650) this.width=650; "Style=" background-image:none;border-bottom:0px;border-left:0px;padding-left:0px; padding-right:0px;border-top:0px;border-right:0px;padding-top:0px; "title=" image "border=" 0 "alt=" image "src=" http ://s3.51cto.com/wyfs02/m00/78/6e/wkiom1z8iktilu13aadxukxvkay457.png "height=" 303 "/>

After acquiring the two variables $pass_new and $pass_conf, the code filters with the mysql_real_escape_string () function, which prevents SQL injection but does not prevent the CSRF attack. The two variables are then directly replaced in the UPDATE statement to perform the database update operation.

Here's another look at the medium level code:

650) this.width=650; "Style=" background-image:none;border-bottom:0px;border-left:0px;padding-left:0px; padding-right:0px;border-top:0px;border-right:0px;padding-top:0px; "title=" image "border=" 0 "alt=" image "src=" http ://s3.51cto.com/wyfs02/m01/78/6e/wkiom1z8ikxjjvapaad4ze5ldpk843.png "height=" 309 "/>

As you can see here, before getting the two variables $pass_new and $pass_conf, use an if statement to determine if the value of "$_server[' Http_referer '" is 127.0.0.1. This is a basic way to defend against CSRF attacks: Verify the HTTP referer field. We can use the previous method again to implement the CSRF attack, and we can see that it has not worked. Let's explain how this defense works.

According to the HTTP protocol, there is a field called Referer in the HTTP header, which records the source address of the HTTP request. For example, the following packet intercepted by the Burpsuite, the data to be submitted to the page is upfile_other.asp, and we are through the Referer field http://192168.80.131/upload_Other.asp this page to initiate the request.

650) this.width=650; "Style=" background-image:none;border-bottom:0px;border-left:0px;padding-left:0px; padding-right:0px;border-top:0px;border-right:0px;padding-top:0px; "title=" image "border=" 0 "alt=" image "src=" http ://s3.51cto.com/wyfs02/m01/78/6e/wkiol1z8iludbfwwaaeoyerirg4136.png "height=" 237 "/>

In general, requests to access a secure restricted page should come from the same site, such as the need to access Http://bank.example/withdraw?account=bob&amount=1000000&for=Mallor , the user must first log in to Bank.example and then trigger the transfer event by clicking on the button on the page. At this point, the Referer value of the transfer request will be the URL of the page where the transfer button is located, usually the address beginning with the Bank.example domain name. And if the hacker wants to carry on the CSRF attack to the bank website, he only constructs the request in his own website, when the user sends the request to the bank through the hacker's website, the request Referer is pointing at the hacker own website. Therefore, to defend against CSRF attacks, the bank website only needs to verify its referer value for each transfer request, if it is a domain name beginning with bank.example, it is legitimate that the request is from the bank website itself. If Referer is a different Web site, it could be a hacker's csrf attack, rejecting the request.

In Dvwa, the administrator modifies the page through the local address 127.0.0.1来 access password, so for any request to change the password, if its referer is not 127.0.0.1, then it is judged to be a csrf attack and rejected.

This method is not foolproof, however, because the value of referer is provided by the browser, and some methods can be used to tamper with the Referer value for some browsers. So hackers can completely change the Referer value of the user's browser to the desired address, so that it can be verified and thus be CSRF attacked.

In addition, even if hackers cannot tamper with referer values, this approach still has problems. Because the Referer value records the user's access to the source, some users believe that this violates their own privacy, especially some organizations worry that the Referer value will disclose some information in the organization intranet to the external network. As a result, users can set their own browser to no longer provide Referer when sending requests. When they visit the bank website normally, the website will be considered as a CSRF attack because the request does not have Referer value, and deny access to legitimate users.

In summary, it is not reliable to validate HTTP Referer fields to prevent CSRF attacks, which is why the medium level of DVWA uses this defense approach. But how to modify the user-side browser Referer value to bypass the defense, I have not yet found the relevant information, this problem is shelved for the time being later.

Finally, to analyze the high level, you can see the difference in the interface first: This requires the administrator to enter the current password before you can reset the password. This is one of the most effective ways to defend against CSRF attacks: two confirmations.

650) this.width=650; "Style=" background-image:none;border-bottom:0px;border-left:0px;padding-left:0px; padding-right:0px;border-top:0px;border-right:0px;padding-top:0px; "title=" image "border=" 0 "alt=" image "src=" http ://s3.51cto.com/wyfs02/m02/78/6f/wkiom1z8ikbagak2aabfeyqja_a418.png "height=" 191 "/>

The so-called two-time confirmation is that when some functions are called two times, such as: When the user is deleted, a prompt dialog box prompts "OK to delete the user?" ”。 The user is required to enter the password two times during the transfer operation. In addition, setting the verification code can also play the same effect.

After two validations, even if the user opens the vulnerability CSRF attack page, it will not be executed directly and requires the user to enter again to complete the attack. In this way, when the user suddenly received a prompt, may be suspicious, will not be obediently.

This article from "a pot of turbid wine" blog, reproduced please contact the author!

DVWA series of CSRF Vulnerability analysis