Shulou(Shulou.com)06/01 Report--

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

After getting the variables $pass_new and $pass_conf, the code uses the mysql_real_escape_string () function to filter, so that although you can prevent SQL injection, but can not prevent CSRF***, these two variables are directly substituted into the UPDATE statement to perform the database update operation.

Let's take a look at the medium-level code:

You can see here that before getting the variables $pass_new and $pass_conf, an if statement is used to determine whether the value of "$_ SERVER ['HTTP_REFERER']" is 127.0.0.1. This is a basic defense against CSRF***: validate the HTTP Referer field. We can use the previous method to implement CSRF***, again and find that it no longer works. Let's explain the principle of this method of defense.

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

In general, the request to access a secure and restricted page should come from the same website, for example, if you need to visit 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 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 an address that begins with the bank.example domain name. If * wants to implement CSRF***, on a bank website, he can only construct a request on his own website. When a user sends a request to a bank through a * * website, the Referer of the request is directed to his own website. Therefore, to defend the CSRF***, bank website, you only need to verify its referer value for each transfer request, and if it is a domain name that begins with bank.example, the request comes from the bank website itself and is legitimate. If Referer is another website, it is possible that the CSRF***, of * * rejected the request.

In DVWA, the administrator accesses the password change page through the local address 127.0.0.1, so any request to change the password whose Referer is not 127.0.0.1 is judged to be CSRF***, and rejected.

However, this approach is not foolproof, because the value of Referer is provided by the browser, for some browsers, there are some ways to tamper with the referer value. Therefore, * you can change the referer value of the user's browser to the desired address, so that you can pass verification and CSRF * *.

In addition, this method is still problematic even if * cannot tamper with the referer value. Because the referer value records the source of the user's access, some users think that this will infringe on their own privacy, especially some organizations worry that the referer value will leak some information from the organization's internal network to the external network. Therefore, the user can set up the browser so that it no longer provides Referer when sending the request. When they visit the bank website normally, the website will be regarded as CSRF because the request does not have a Referer value, and legitimate users will be denied access.

In summary, it is unreliable to prevent CSRF*** by validating the HTTP Referer field, which is why the medium level of DVWA adopts this method of defense. But how to modify the Referer value of the client browser to bypass the defense, I haven't found the relevant information yet, so I'll put this problem on hold and fix it later.

Finally, if you analyze the high level, you can first see the difference on the interface: the administrator is required to enter the current password before you can reset the password. This is currently a very effective way to defend against CSRF***: second confirmation.

The so-called secondary confirmation is the second verification when calling certain functions, such as: when deleting a user, a prompt dialog box is generated that prompts "are you sure you want to delete the user?" . During the transfer operation, the user is required to enter a secondary password. In addition, setting a CAPTCHA can have the same effect.

After the second verification, even if the user opens the vulnerability CSRF*** page, it will not be executed directly, but will need to be typed again to complete the *. In this way, when the user suddenly receives the prompt, he may be skeptical and will no longer be obediently hit.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.