Cross-Site Request Forgery (CSRF) in Web Security Testing (1)

Bkjia.com exclusive Article] Cross-Site Request Forgery (CSRF) is known as the "sleeping giant" among many vulnerabilities in the Web security field. Its threat level is also known as "reputation. This article briefly introduces this vulnerability and describes in detail the cause of this vulnerability, as well as the specific methods and examples for testing the black box and gray box vulnerabilities, finally, I have provided some suggestions to prevent this attack. I hope this article will inspire readers in their security tests.

I. CSRF Overview

First, let's take a look at what Cross-Site Request Forgery (CSRF) is )? Cross-Site Request Forgery is an attack method that allows end users to perform unintentional operations on the currently logged-on Web application. Attackers can force users of a Web application to execute the operations they choose by using a few social engineering tricks, such as links sent via email or chat software. For example, if a user logs on to an online bank to check his deposit balance, he does not leave the online banking system and goes to his favorite forum to fill the water, if attackers carefully construct a malicious link in the Forum and trick the user into clicking the link, the user's funds in the online bank account may be transferred to the account specified by the attacker.
When CSRF launches attacks against common users, the data and operation commands of end users are seriously threatened. When the attacked end users have an administrator account, the CSRF attack threatens the entire Web application.

Ii. Causes of CSRF

Whether cross-site Request Forgery can be successful is inseparable from the following aspects: browser-based session processing. Attackers can understand the URL of Web applications, applications rely on to manage the transparency of session information to browsers and various HTML tags that can cause resource requests. The following are explanations.

First, let's take a look at how Web browsers process session information such as cookies and HTTP identity authentication information. Currently, the browser automatically sends the information that identifies the user dialog without user intervention. In other words, when the browser sends the identity information, the user cannot feel it at all. Assume that there is A Web application on Site A, and the victim has passed identity authentication on the site, the site will send A cookie to the victim as A response, what is the role of this cookie? The website is primarily used as a sign of user sessions. If the site receives a request with the cookie of the victim, it will regard the request as sent by the victim who has logged on. Generally, after the browser receives the cookie set by the site, the browser automatically sends a request to the site together with the cookie.

Then, let's discuss the attacker's knowledge about the Web application URL. If the application does not use session-related information in the URL, then, you can analyze the code or access the application and view the URLs embedded in HTML/JavaScript and the forms to understand the URL, parameters, and allowed values related to the application.

Next, let's discuss the transparency of the information that the application uses to manage sessions to the browser. We know that, to improve the convenience of Web applications, it is used to manage session information, such as cookies or HTTP-based identity authentication, such as basic HTTP Authentication and non-form-based authentication, these information is stored by the browser and automatically retained whenever a request is sent to an application requiring authentication. That is to say, the browser can access session management information. If a Web application relies entirely on this 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, cross-site request forgery attacks can be launched without it, but with it, the attack is easier. There are multiple HTML tags. If these tags appear on the page, the browser will immediately access the http [s] resource. For example, the img tag is one of them.

For the sake of simplicity, we will discuss the get url here, but the content discussed here also applies to POST requests ). If the victim has been authenticated, the cookie will be automatically sent when another request is submitted, where the user is accessing an application on www.example.com ).

Figure 1 The browser automatically sends a cookie when sending a request

So, under what circumstances will this GET request be sent? There are many possibilities. First, this GET request may be triggered when the user uses the Web application normally. Second, this GET request is also triggered when you type the URL directly in the address bar of the browser. In addition, the user clicks the link pointing to the URL, even if the link is outside the application, this GET request is also triggered.

For an application, it cannot distinguish these differences. In particular, the third type may be very dangerous. There are many technologies and vulnerabilities) to hide the real properties of a link. Links can be embedded in email messages, or appear on bad Web sites, and then entice users to browse the site, for example, the link appears in other Web sites on other hosts, HTML-format email messages, and so on) and points to application resources. If the user clicks the link, the browser sends a GET request to the Web application because the user has already passed the authentication of the Web application on the site, and send the verification information containing the cookie of the session id together. This will cause a valid operation on the Web Application -- this operation may not be desired by the user, for example, a link that causes malicious transfer on the network bank, and so on.

As mentioned above, you can launch an attack by using tags such as img without even clicking a specific link. Assume that the attacker sent an email to the user to trick the user into accessing a URL, which points to a page containing the following HTML content, which has been simplified:

[html][body]...(img src=”https://www.company.example/action” width=”0” height=”0”)...[/body][/html] Replace [] with <>

When the browser displays the page, it will also try to display the image with the specified width of 0, that is, the image is invisible-this will automatically send a request to the Web application on the site. It is important that the browser triggers a request based on the URL specified in the src field, regardless of whether the image URL actually points to an image or not. Of course, there is a premise that the browser does not prohibit image downloading-in fact, all browsers are configured to allow image downloading, because the availability of most Web applications will be greatly reduced after the image is disabled. The HTML Tag issues related to cross-site request forgery are summarized as follows:

There are many tags on the page, which will automatically send HTTP request img tags );

The browser cannot determine whether the resources referenced by the img Tag are images or harmful;

When loading an image, the position of the involved image is not taken into account, that is, the form and image do not have to be on the same host or even in the same domain. Although this is a very convenient feature, it creates obstacles for application isolation. Because HTML content unrelated to Web applications can reference various components in applications, and the fact that the browser can automatically construct a valid request for the application results in this attack. This means that the correct URL must contain information related to the user session, but the attacker cannot know the information, so it is impossible to identify such a URL.

Cross-Site Request Forgery may be more serious for work platforms that integrate the mail/browser functions, because, only one email containing the image is displayed, causing requests and related browser cookies to be sent to the Web application together.

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

(img src=”https://[attacker]/picture.gif” width=”0” height=”0”) Replace () with <>

Here, [attacker] is a site under the control of attackers and redirects http: // [attacker]/picture. gif to http: // [thirdparty]/action through the redirection mechanism.
If the session information of a Web application is provided by a browser, such Web applications are vulnerable to attacks, these include those applications that only rely on the HTTP authentication mechanism, because the browser knows the authentication information and will automatically attach the authentication information when sending each request. Of course, this does not include form-based authentication. It only sends out once and generates a form for session information-of course, if such information is simply transmitted as a cookie, this has returned to the previous situation.