Expert in-depth analysis of Cross-Site Request Forgery Vulnerability (on)

When a poor Web site causes your browser to perform unwilling activities on a trusted site, we say a Cross-Site Request Forgery (CSRF) attack has occurred. These attacks are hailed as "sleeping giants" in Web-based vulnerabilities, because many websites on the Internet are undefended, and they have been ignored by web development and security communities.

I. Overview

When a poor Web site causes your browser to perform unwilling activities on a trusted site, we say a Cross-Site Request Forgery (CSRF) attack has occurred. Cross-Site Request Forgery (XSRF) attacks are also called cross-site reference forgery (XSRF) attacks, session overlapping attacks, and obfuscation agent attacks. We use the term CSRF because it is the most common term used to describe such attacks. These attacks are hailed as "sleeping giants" in Web-based vulnerabilities, because many websites on the Internet are undefended, and they have been ignored by the Web development community and security community. Currently, CSRF attacks have not been included in the Web security threat classification, and CSRF attacks are rarely described in academic and technical literature. CSRF attacks are easy to identify, exploit, and repair. They exist because Web developers are ignorant of the root cause and severity of CSRF attacks. Web developers may also mistakenly believe that the defense against more famous cross-site scripting (XSS) attacks can also defend against CSRF attacks.

In the next article, we will introduce several severe CSRF vulnerabilities discovered on some large websites this year. These vulnerabilities allow attackers to collect users' email addresses, infringes on user privacy and controls user accounts. At the same time, we will introduce the Transformation Scheme for the server, so that the site can fully defend against CSRF attacks. This solution has multiple advantages, because it does not use the server status and does not impede typical web browsing activities. In addition, we also introduced a browser plug-in for the client, which can protect users from some types of CSRF attacks. Server-side protection measures allow the site to fully defend against CSRF attacks, while client-side protection measures allow users to take preventive measures in advance, so that the website can be protected against CSRF attacks even if no protection measures are taken. Although Web developers already have tools to defend against such attacks, they still hope that they can improve their awareness of CSRF attacks.

Ii. Principles of Cross-Site Request Forgery

In order to facilitate the reader's understanding of the Cross-Site Request Forgery Vulnerability, the following example is used. Figure 1, Figure 2, and figure 3 introduce the general principle of CSRF attacks.

498) this. style. width = 498; "border = 0>

Figure 1 establish an authenticated session between the browser and the website

Here, the Web browser has established an authenticated session with a trusted site. Then, as long as the request is sent through the authenticated session of the Web browser, it is regarded as a trusted action.

498) this. style. width = 498; "border = 0>

Figure 2 valid requests sent by the browser

The browser is sending a valid request, that is, the Web browser attempts to perform a trusted action. A trusted website has been confirmed that the Web browser has passed authentication, so this action will be executed.

498) this. style. width = 498; "border = 0>

Figure 3 valid requests forged by malicious sites

A csrf attack occurred. The attacked site causes the browser to send a request to a trusted site. The trusted site believes that all requests from the Web browser are authenticated valid requests, so the "trusted action" is executed ". The root cause of CSRF attacks is that the Web site verifies the Web browser rather than the user. The following uses a specific example to describe CSRF attacks in detail.

Assume that a website has a CSRF Attack Vulnerability. For example, a Web-based email website allows users to send and receive emails. This site uses an implicit authentication method to authenticate the user's identity. Its page, such as the e-mail button.

{form action="http://example.com/send_email.htm" method="GET"} Recipient’s Email address: {input type="text" name="to"} Subject: {input type="text" name="subject"} Message: {textarea name="msg"}{/textarea} {input type="submit" value="Send Email"} {/form}

: When a user at example.com clicks "Send Email", the data entered by the user is sent to http://example.com/send_email.htmthrough a GET request. Because the GET request simply attaches the form data to the URL, the URL sent by the user is as follows. Assume that the recipient entered by the user is "bob@example.com", the subject is "hello", and the message is "What's your name ?" :

http://example.com/send_email.htm?to=bob%40example.com&subject=hello&msg=What%27s+your+name%3F

Note that the data of the preceding URL has been encoded, and @ is converted to % 40.

Send an email to the recipient specified by the user based on the received data. Finally, all send_email.htm does is extract data and then use the data to complete an action. It does not care where the request comes from, and it only cares about the received request. This means that even if the above URL is manually entered by the user to his browser, example.com will also send an email as usual. For example, if the user clicks three URLs in the address bar of the browser, the send_email.htm page will send three emails (sent to Bob, Alice, and Carol respectively ):

http://example.com/send_email.htm?to=bob%40example.com&subject=hi+Bob&msg=test http://example.com/send_email.htm?to=alice%40example.com&subject=hi+Alice&msg=test http://example.com/send_email.htm?to=carol%40example.com&subject=hi+Carol&msg=test

Here, the csrf attack occurs. The original cause is that send_email.htm extracts all received data and sends an email. The cursor does not check the data in the form of the compose.htm page. For this reason, the attacker only needs to allow the user to send a request to send_email.htm. then, the send_email.htm page will cause example.com to send an email. It is important that the email is sent with the username and contains the attacker's role.