I. Introduction to CSRF

CSRF (Cross-site Request Forgery)

Cross-site request forgery, also known as “OneClick Attack” or Session Riding, often abbreviated to CSRF or XSRF, is a malicious use of a website.

The figure above shows A simple model of CSRF attack. The user visits the malicious website B, and the HTTP message returned by the malicious website B requires the user to visit website A. Since there may already be A trust relationship between the user and website A, the request will be executed just as the real one sent by the user.

Second, the harm of CSRF attack

Attackers steal your identity, in the name of your sending malicious request, the request for server is perfectly legal, but finished the attacker’s expectation of an operation, such as in the name of your email, send messages, to steal your account, add a system administrator, or even to buy goods, virtual currency transfer, etc.

If the spam sent by CSRF is accompanied by a worm link, those friends who receive the harmful information will also spread the harmful information if they open the link in the private message, and tens of thousands of users will have their data stolen and planted Trojan horses. An entire website’s application can crash in an instant, users complain, users lose, and the company’s reputation plummets or even goes out of business. Once on MSN, a 19-year-old American named Samy took advantage of the BACKGROUND flaw in THE CSS to infect more than 1 million users with his worm in a few hours. Although the worm did not destroy the entire application, it just added a sentence “Samy is my idol” to the end of each user’s signature. But if these vulnerabilities are exploited by malicious users, as happened to Sina Weibo, the consequences can be disastrous.

Web A is A website with CSRF vulnerability, Web B is A malicious website constructed by an attacker, and User C is A legitimate User of Web A.

CSRF attack principle and process

1. User C opens A browser, accesses trusted website A, and enters the user name and password to request to log in to website A. 2.

2. After the user information is verified, website A generates Cookie information and returns it to the browser. At this time, the user logs in to website A successfully and can send requests to website A normally.

3. Before the user exits website A, open A TAB page in the same browser to visit website B;

4. After receiving the user’s request, website B returns some offensive codes and sends A request to visit the third party site A;

5. After receiving these offensive codes, the browser, according to the request of website B, carries Cookie information and sends A request to website A without the user’s knowledge. Website A does not know that the request is actually initiated by B, so it will process the request with C’s permission according to the Cookie information of user C, resulting in the malicious code from Website B being executed.

For example:

Simple version:

If the blogpark had a GET interface to follow, the blogUserGuid parameter would obviously be the Id of the person to follow, as follows:

I just need to put an IMG tag in one of my blog posts:

So as soon as someone opens my blog, it automatically follows me.

The upgrade version:

The blogosphere still has a focus interface, but it has restricted access to POST requests only. This time to make a third party page, but it contains the form submission code, and then spread through QQ, mailbox and other social tools to lure users to open, that opened the blog park users will be fooled.

To correct an iframe problem before going into the example, someone will write this directly on a third party page. As follows:

Because of the same origin policy, the iframe content cannot be loaded at all, so the form submission will not be executed.

PS: I’ve tried Chrome, IE11, Firefox, and it’s all the same.

So it can be solved by embedding one more layer of pages, as follows:

First display page (test) :

Second hidden page (test2) :

This would solve the problem of adding an extra layer of iframe, as pages without embedded iframe would be redirected, thus reducing the vulnerability of attacks. In addition, our Test page does not use XMLHTTPRequest to send POST requests because there are cross-domain issues, whereas forms can POST data across domains.

The advanced version:

If the blog park still has a focused interface that restricts posts, but the content is posted directly into HTML (unfiltered), then it is exposed to XSS attacks. You can embed the above code directly into a blog post, so that whenever someone opens my blog post, they will automatically follow me. This combination of attacks is called XSRF.

4. CSRF vulnerability detection

Detection of CSRF vulnerability is a tedious work. The simplest method is to capture a normal request packet, remove the Referer field and then resubmit it. If the submission is still valid, it can basically confirm the existence of CSRF vulnerability.

With the deepening of CSRF vulnerability research, some special CSRF vulnerability detection tools have emerged, such as CSRFTester and CSRF Request Builder.

Taking CSRFTester as an example, the test principles of CSRF vulnerability detection tool are as follows:

When testing with CSRFTester, we first need to grab all the links we visited in the browser, all the forms and other information, and then resubmit by modifying the corresponding forms and other information in CSRFTester, which is equivalent to a forged client request. If the modified test request is successfully accepted by the website server, the CSRF vulnerability exists. Of course, this tool can also be used to carry out CSRF attacks.

5. CSRF vulnerability defense

At present, there are three main defense strategies against CSRF attacks: verifying HTTP Referer field; Add token to request address and verify; Customize and validate properties in HTTP headers.

1. Use POST as much as possible and limit GET

The GET interface is too easy to use for CSRF attacks, as the first example shows, simply by constructing an IMG tag, which is unfiltered data.

You are advised to limit the use of the interface to POST. GET is invalid to reduce attack risks.

Of course, POST is not foolproof. An attacker can simply create a form, but it needs to be done on a third-party page, which increases the possibility of exposure.

2. Cookie policy of the browser

By default, Internet Explorer 6, 7, 8, and Safari block sending third-party local cookies.

However, Firefox2, 3, Opera, Chrome, and Android do not block CSRF attacks, so using the browser Cookie policy to defend against CSRF attacks is not reliable, but can only reduce the risk.

PS: Cookies are divided into two types

Session cookies (which expire after the browser closes and are stored in memory),

Third-party cookies (cookies that expire after Exprie time and are saved locally).

PS: In addition, if the web site returns an HTTP Header containing the P3P Header, it will allow the browser to send third-party cookies.

3. Add a verification code

A verification code that forces the user to interact with the application before completing the final request. In general, captchas are good at deterring CSRF attacks.

But for the sake of user experience, sites can’t add captcha codes to all operations.

Therefore, captchas can only be used as an auxiliary means, not as the main solution.

4, Referer Check

The most common use of Referer Check on the Web is to prevent image theft.

In the same way, the Referer Check can be used to Check whether the request is coming from a legitimate “source” (whether the Referer value is the specified page, or the domain of the site), and if neither is, it is most likely a CSRF attack.

However, because the server does not always have access to the Referer, it cannot be used as a primary means of CSRF defense.

However, Referer Check is a feasible method to monitor the occurrence of CSRF attacks.

5 、Anti CSRF Token

Now the industry defense against CSRF, the consistent approach is to use a Token (Anti CSRF Token).

Example:

  • A user visits a form page.

  • The server generates a Token and places it in the user’s Session or in the browser’s Cookie.

  • Attach the Token parameter to the page form.

  • After a user submits a request, the server verifies whether the Token in the form is the same as the Token in the user Session (or Cookies). If the Token in the form is the same, the request is valid. If the Token in the form is not invalid, the request is invalid.

The value of this Token must be random and unpredictable. Because of the Token, the attacker can no longer construct a request with a valid Token to carry out a CSRF attack. In addition, when using tokens, you should pay attention to the confidentiality of tokens. Try to change sensitive operations from GET to POST and submit them in form or AJAX to avoid Token disclosure.

Note:

CSRF tokens are only used to defend against CSRF attacks. When the site also has XSS vulnerability, then this solution is also empty.

Therefore, XSS problems should be solved using XSS defense solutions.

Especially in some forums and other websites that support users to publish their own content, hackers can publish their own personal website address. Since the system also adds a token to the address, the hacker can get the token on his own website and launch a CSRF attack right away. In order to avoid this, the system can add a judgment when adding the token, if the link is linked to their own site, add the token later, if it is to the Internet, do not add. However, even if the CSRFtoken is not attached to the request as a parameter, a hacker’s site can also obtain the token value via the Referer to launch a CSRF attack. This is why some users prefer to turn off the browser Referer manually.

  • Customize and validate properties in HTTP headers

This method also uses the token and validates it. Unlike the previous method, instead of placing the token in the HTTP request as a parameter, it places it in a custom attribute in the HTTP header. With the XMLHttpRequest class, you can add the CSRFToken HTTP header attribute and put the token value into all of the class requests at once. This eliminates the inconvenience of adding the token to the request in the previous method, and the XMLHttpRequest address is not logged in the browser’s address bar, and the token is not leaked to other sites through the Referer.

However, this approach has significant limitations. XMLHttpRequest is usually used for asynchronous partial page refresh in Ajax methods. Not all requests are suitable to be initiated with this class, and the page obtained through this class cannot be recorded by the browser, thus making it inconvenient for users to move forward, backward, refresh, and save. In addition, for legacy systems without CSRF protection, this approach to protection requires that all requests be converted to XMLHttpRequest requests, which is almost an entire web site rewrite, an unacceptable cost.

Finally, XSS

Malicious attackers insert malicious Script codes into Web pages. When users browse the page, the Script codes embedded in the Web will be executed, so as to achieve the purpose of malicious attacks on users.

XSS attacks fall into two categories

  • From the internal attack: mainly refers to the use of the vulnerability of the program itself, the construction of cross-site statements, such as: DVBBS showerror. Asp cross-site vulnerability.
  • Attacks from the outside: mainly refers to their own construction of XSS cross-site vulnerability web pages or looking for non-target computers have cross-site vulnerability web pages. For example, when we want to infiltrate a site, we construct a web page with cross-site vulnerabilities, and then construct cross-site statements, by combining other technologies, such as social engineering, etc., to deceive the administrator of the target server to open.

XSS is divided into storage type and reflection type

  • Stored XSS: Stored XSS, persistent, code is stored in the server, such as in personal information or published articles, add code, if not filtered or not strictly filtered, then the code will be stored in the server, when the user visits the page triggered code execution. This type of XSS is dangerous, prone to worms and cookie theft (although there is a DOM type of XSS, it is still included in the storage type).
  • Reflective XSS: non-persistent, requires the user to trick themselves into clicking the link to trigger the XSS code (there is no such page or content on the server), which is usually found on the search page.