Cross-site request forgery (CSRF) for web security testing

Cross-site request forgery (that is, CSRF) is known by the Web security community as a "sleeping giant" in many vulnerabilities, and the extent of its threat can be seen as a "reputation". This article will provide a brief description of the vulnerability, and details the cause of the vulnerability, as well as the specific methods and examples of black-box and gray-box testing of the vulnerability, and finally, some suggestions to prevent the attack, I hope this article on the reader's security test can be inspired.

I. Overview of CSRF

Let's start by understanding what is cross-site request forgery (CSRF)? Cross-site request forgery is an attack method that compelling an end user to perform a non-intended operation on a currently logged-on Web application. An attacker could force a user of a Web application to perform an attacker's chosen action by using a few social engineering tricks, such as a link sent by email or chat software. For example, if a user logs on to a network bank to view his or her deposit balance, he does not exit the Internet banking system and goes to his favorite forum to pour water, if the attacker constructs a malicious link in the forum and convinces the user to click on the link, Then the user's funds in the network bank account may be transferred to the account specified by the attacker.
When CSRF attacks against an ordinary user, it poses a serious threat to the end user's data and operational instructions, and the CSRF attack endangers the entire Web application when the compromised end user has an administrator account.

Ii. Causes of CSRF

Cross-site request forgery can be successful, and the following aspects are inseparable, respectively, the browser to the session processing, the attacker's understanding of the Web application about the URL, the application depends on the management of the session information on the browser transparency and a variety of can raise resources to request HTML tags. explained separately below.

First, let's look at some of the ways Web browsers handle session information such as cookies and HTTP authentication information. Currently, the browser automatically sends information that identifies the user's conversation without user intervention, in other words, when the browser sends the identity information, the user does not feel it at all. Given that there is a Web application on site A and that the victim is already authenticated on that site, the site sends a cookie to the victim in response, what is the role of this cookie? The main is the site as a user session flag, that is, if the site received a cookie with the victim's request, then it will treat this request as a registered victim sent. In general, when a browser receives a cookie from a site setting, the browser will "automatically" send it along with the cookie whenever a request is sent to that site.

Then, let's discuss the attacker's understanding of the Web application URL. If the application does not use session-related information in the URL, then through code analysis or by accessing the application and viewing the URL in the embedded Html/javascript and the form to learn about the URL, parameters, and allowable values of the application.

Next, let's discuss the transparency of the browser by the information that the application relies on to manage the session. We know that in order to improve the convenience of Web applications, the information used to manage sessions, such as cookies or HTTP-based authentication (such as HTTP Basic authentication, non-form-based authentication), is stored by the browser, and automatically piggyback on this information whenever a request is sent to an application that requires authentication. That is, the browser can access session management information, and if the Web application relies entirely on such information to identify a user session, this creates a condition for cross-site request forgery.

The three factors mentioned above are the necessary conditions for cross-site request forgery attacks, and the following is a "icing on the cake" factor, that is, no it can also launch cross-site request forgery attack, but with it can make the attack easier. This is the existence of a variety of HTML tags, if the page appears within these tags, will immediately cause browser access to http[s] resources, such as tag IMG is one of them.

For the sake of simplicity, we discuss the URL of the Get method here (but the same thing discussed here applies to post requests). If the victim is authenticated, the cookie is automatically sent when he submits another request (where the user is accessing an application on www.example.com).

Figure 1 The browser sends the request while the cookie is automatically sent

So, under what circumstances would it cause the GET request to be sent? This can be a lot of possibilities, first of all, when the user is working with the Web application, it is possible to raise the GET request, and secondly, when the user types the URL directly in the browser address bar, the GET request is also raised, and the user clicks the link to the URL, even if the link is outside the application , the GET request is also raised.

For applications, it is impossible to distinguish these differences from the above. The third, in particular, may be very dangerous. There are many techniques (and vulnerabilities) that can hide the true properties of a link. A link can be embedded in an e-mail message, or it can appear on a malicious Web site, and then entice a user to browse the site, such as linking to content that is now located on other hosts (other Web sites, HTML-formatted e-mail messages, and so on) and pointing to the resources of the application. If the user clicks the link, the browser issues a GET request to the Web application, as he has passed the authentication of the Web application on the site, and sends the authentication information (the cookie that contains the session ID) to the past. This causes a valid action to be performed on the Web application-the action may not be desired by the user, such as a malicious link that causes a transfer on the network bank, and so on.

As mentioned earlier, by using tags such as IMG, you do not even need to click on specific links to launch the offensive. Suppose an attacker sends an e-mail message to a user to trick the user into accessing a URL that points to a page that contains the following HTML content (note that the content is streamlined):

[Html][body] ... (img src= "https://www.company.example/action" width= "0" height= "0")... [/body][/html]

Replace [] with a <>

When the browser displays the page, it will also try to display the image with a specified width of 0, that is, the image is not visible-this causes a request to be sent automatically to the Web application in the site. It is important that the browser, regardless of whether the image URL actually points to a picture, will trigger a request at that address as long as the URL is specified in the SRC field. Of course, there is a premise that the browser does not prohibit the download of images-in fact, the browser is configured to allow the download of images, because after disabling the image, the usability of most Web applications will be greatly compromised. The problem with HTML tags related to cross-site request forgery is summarized as follows:

There are many labels on the page that will cause the HTTP request to be sent automatically (the IMG tag is one of them);

The browser cannot determine whether the resource referenced by the IMG tag is an image and is not harmful;

When images are loaded, the location of the images involved is not considered at all, i.e. forms and images do not have to be on the same host, or even in the same domain. While this is a very handy feature, it gives the application a barrier to manufacturing isolation. It is the fact that HTML content unrelated to the Web application can refer to the various components in the application, and that the browser can automatically construct a valid request for the application, which leads to the occurrence of such an attack. This means that the correct URL must contain information about the user's session, but the attacker is not aware of the information, so it is not possible to identify such a URL.

For a work platform with integrated mail/browser capabilities, cross-site request forgery can be more serious, because simply displaying an email containing the image causes the request and the browser cookie to be sent to the Web application.

In addition, attackers can disguise these things, such as referencing seemingly legitimate image URLs, such as

(img src= "https://[attacker]/picture.gif" width= "0" height= "0")

Here, [attacker] is the site under the control of the attacker and will http://[attacker]/picture through the redirection mechanism. GIF steering Http://[thirdparty]/action.
If the Web application's session information is provided entirely by the browser, then such web applications are vulnerable, including those that rely only on the HTTP authentication mechanism, because the browser knows the authentication information, These verification messages are automatically included when each request is sent. Of course, this does not include forms-based authentication, which is issued only once and generates a form for session information--and, of course, if such information is simply passed as a cookie, there is a return to the previous situation.

Three, cross-site request forgery scenario analysis

If the victim is already logged into a Web management application on a firewall. We know that when a user logs on, the Web app authenticates, usually requiring the user to provide their user name and password, which is authenticated if the user name and password are correct, and then the Web App holds a small text file, the cookie, that holds the session information on the client.

Suppose a firewall has a Web-based management interface, which we call a firewall Web manager, which has a feature or a page that allows authenticated users to delete a specified rule by a rule number, or to delete all configured rules by entering "*"-this is a very dangerous feature indeed. The delete page appears as follows. If the form (which we have already simplified) causes a GET request, the request will look like this

Https://[target]/fwmgt/delete?rule=1
(Delete a rule)
https://[target]/fwmgt/delete?rule=*
(Delete all rules).

The example was deliberately naïve, in order to make it easier to explain the dangers of csrf. The page that deletes the firewall rule is as follows:

Figure 2 Firewall Management page

Therefore, if we type the value "*" and press the Delete button, the following GET request is submitted:

https://www.company.example/fwmgt/delete?rule=*

The result of course is to remove all firewall rules, hehe, the consequences are very serious ah! As shown in the following:

Figure 3 Deleting all firewall rules

In fact, this is not the only possible scenario. Users can also manually submit Urlhttps://[target]/fwmgt/delete? Rule =* to achieve the same effect. or by clicking a link directly to the URL above or by redirecting to the URL above. Or, you can also access an HTML page that embeds an IMG tag that points to the same URL. In these cases, if the user is currently logged in to the firewall manager, the request succeeds and modifies the firewall's configuration.

In addition, we can assume that attacks are targeted at sensitive applications, automate auction bids, transfer, order, change the configuration of key software components, and more.

More interestingly, these vulnerabilities can be exploited behind firewalls, as long as the attacked link is accessible to the victim without having to be directly accessible by the attacker.

In particular, it can be any intranet Web server, for example, the previously mentioned firewall management workstation, which is unlikely to be exposed to the Internet. For those applications that can be used as attack vectors, which have an attack target (such as a Web mail application), the situation is even worse: if such an application is vulnerable, it is obvious that the user is already logged in to the program when reading a letter containing the CSRF attack, which targets the Web mail application. and have the mail application perform actions such as deleting letters, sending messages, and so on, and these actions appear to be what the user is doing.

Four, black box test

For a black-box test, you need to know the URL of the restricted (authenticated) zone. If you have a valid certificate, you can play the role of both the attacker and the victim. In this case, you will only be able to learn about the URLs that are being tested by browsing the application. Otherwise, if no valid certificate is available, an actual attack must be organized to lure a legitimate logged-in user to click on an appropriate link, which can be done through social engineering.

However, the test case can be constructed as follows:

Change u to the URL under test, e.g. u=http://www.example.com/action

Construct an HTML page that contains the reference URL u (which specifies all relevant parameters; It is simple to use Get mode, if you are using a POST request, you need to appeal to some JavaScript code) HTTP request;

Ensure that the legitimate user has logged in to the application;

Lure him to click on a link that points to the URL under test (if you can't impersonate a user, you need social engineering);

Observe the results, such as detecting whether the Web server has performed the request.

Five, Ash box test

When evaluating an application for security, investigate whether its session management is vulnerable. If session management relies entirely on the client's value (which is also available to the browser), the application is vulnerable. With these client values, we understand the cookie and HTTP Authentication certificate (Basic authentication and other forms of HTTP authentication; Not form-based authentication, application-level authentication). For applications that do not have this vulnerability, it must include information about session sessions in the URL, and take a form that makes the user unrecognizable or unforeseeable ([3] uses the term secret to represent the unit of information).

Resources that can be accessed through HTTP GET requests are vulnerable to weaknesses, but post requests can be automated by JavaScript and vulnerable to attacks, so it is not sufficient to use post alone to prevent the CSRF vulnerability from occurring.

Six, cross-site request forgery countermeasures

The threat of cross-site request forgery is so great that both the user and the developer should be given enough attention, and here are some useful suggestions for Web application end users and Web application developers.

User

Because CSRF vulnerabilities are trending, it is recommended that users follow best practices to mitigate risk, and the habits that can reduce risk include:

Log out immediately after using the Web application

Do not let the browser save the username/password, do not let the site "Remember" you do not use the same browser to access sensitive applications and random surfing, if you have to do multiple things at the same time, it is best to use a separate browser.

Additional risk is associated with software that supports the HTM format for mail/browser integration and the integration of the news reader/browser, since it is possible to use such software with extreme caution as long as the message is viewed or the news may be forced to perform an attack.

Development staff

Developers should add information about the session to the URL. The attack type succeeds because the session is uniquely identified by the cookie and is automatically sent by the browser.

If we generate other relevant information for the session at the URL level, it can create more obstacles for the attacker to understand the structure of the URL in order to launch the attack.

As with other countermeasures, although this problem cannot be solved, it can make it more difficult to exploit the vulnerability, such as using post instead of get. While a POST request can be emulated by JavaScript, it increases the difficulty of launching the attack. Using an intermediate confirmation page can also bring the same effect, such as "Are you sure you want to do this?" "Page. Although attackers can circumvent these measures, these measures provide the difficulty of implementing an attack. Therefore, you cannot rely entirely on these tools to protect your application. The automatic logout mechanism can also mitigate the damage caused by this attack, but it ultimately depends on the situation (a user who is dealing with a network banking program with this vulnerability all day is far more at risk than a user who temporarily uses the same network bank).

Vii. Summary

Cross-site request forgery, or CSRF, is a very dangerous web security threat, known as the "Sleeping Giant" by the Web security community, and its threat level is seen as a "reputation". This article not only introduces the cross-site request forgery itself, but also explains the cause of the vulnerability, the specific methods and examples of black box test and gray Box test for the vulnerability, and finally makes some suggestions to prevent the attack, hoping that this article can enlighten the readers ' safety test.

Cross-site request forgery (CSRF) for web security testing