Recently, I have written a little bit of front-end code, using the restful style of front-end and back-end separation, but when asked about security issues during the review, I found that I had not considered this aspect, so here is to think about how to prevent CSRF and XSS in the restful API scenario of front-end and back-end separation. and XSS are two common web attacks.


About CSRF and XSS is what, other resources on the network is a lot, in my nothing (in fact, now is nothing), I think White Hat on Web Security this book let me understand a lot of concepts, in addition, just graduated from the The company also let me know the existence of this thing: OWASP Top 10 Web Application Security Risks. Here I will combine their own understanding of the same two kinds of attacks are what, and then the difference is what, because I did not understand the difference between them at the beginning, I think it is the same thing ah, after the experience of testing, it is better to understand where the difference lies.

From these two descriptions, here first, the source of the problem is different, one is that you visit the untrusted source, one is that you do not visit the untrusted source, but the place you visit is not strong enough to be attacked, thus causing you to be hurt; however, the consequences caused by these two are somewhat similar, for example, both can be constructed to let you bank transfer requests, compared to XSS than CSRF is a little more difficult to prevent. Below, we will talk about how to prevent each of these two attacks.

CSRF defense

First, let’s talk about CSRF defense, from the previous description, you can know that in general, CSRF attacks are cross-site, that is, from A to B, from this feature, then some simple and effective way of operation is to prohibit cross-site access, practical operations are.

Whitelist filtering does not always work, as mentioned earlier, in most cases the Origin and Referer fields are present, but in what cases are they not? This depends on the browser implementation, in general browsers (popular chrome, firefix, safari, IE) will not have these two fields in the following cases.

When these two fields are not available, is there nothing you can do? That’s not true, in fact, many common frameworks now provide CSRF defense, their approach is: the

The idea is that if you cross-site, then you can not get my site on a dynamic thing: for example, you open the malicious site A, although the malicious site A can send a request to the site B, but, because my site B on the form have CSRF_TOKEN check, you malicious site A can not get this CSRF_TOKEN, then there is no way to launch the attack.

For example, if your gmail receives an email that contains a malicious attack script against gmail, once you check this email, triggers a pull of the malicious script, and is executed by the browser, then the malicious script simulates a request to modify the gmail configuration and sends it to gmail. Since the context of this script is on gmail, it can get CSRF_TOKEN and skip your CSRF defense, so you are also attacked.

This time is to offer the last big trick, but also our usual most annoying trick: CAPTCHA, so usually in the input CAPTCHA or re-enter the password to confirm the time, the heart of the grievance less, because this is really for your security considerations.

So for restful scenarios, if purely stateless, then certainly CSRF hanging, so if we use restful in the WEB scenario, you can combine the WEB cookie features, first a layer of CSRF filtering, before the restful business processing, in short

XSS defense

Unlike CSRF, the main risk of XSS comes from the lack of defense against user input. Malicious users can submit carefully constructed malicious input to the system and have it displayed in the wrong form, leading to attacks on other customers who normally access the system. It is easy to defend against this, as it is just a matter of verifying the user’s input, but the input is so extensive that it is usually a very difficult task to be comprehensive and requires thorough consideration and testing.

XSS is not only a simple form text input may exist attack points, file uploads are often an important entry point, for example, your background is written in PHP, if you do not handle the user upload php files, it is likely that the user uploads a PHP file, and then the next time it is accessed becomes the execution of this PHP file, resulting in server attacks, this is more serious.

Therefore, in a REST scenario, the main difficulty in targeting XSS attacks is still: 1.

  1. the formatting of user input to ensure that there are no special characters for the attack.
  2. the display of user input requires additional attention to ensure that special characters are escaped.