Overview
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.
CSRF and XSS
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.
CSRF
CSRF’s full name is: Cross Site Request Forgery, Chinese called cross-site request forgery, as the name implies, this attack is a cross-site attack, the way you open a site A, but the site A placed on the malicious code, the malicious code will forge your request to visit the site B, if you have previously used site B, and keep the site B login status and so on. If you’ve used Site B before and kept Site B logged in or something like that, then your state at Site B could be vulnerable. This is also an important reason why we often say, don’t open unknown images and HTML codes in emails and don’t just visit some bad websites.
XSS
XSS is similar to CSRF, but the source of XSS attack is that you are normally visiting a normal website, but, because the designer of the website is not designed properly, for example, a forum does not check the user’s input, when you browse the forum posts, a malicious forum user carefully constructed an input data that can modify the HTML code of the forum (in the reply to a post or create a post in the Then the forum will display the malicious user’s input as a post, and you happen to visit the post, then the carefully constructed code will be executed by your browser, thus allowing the malicious user to succeed in his purpose.
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.
- B site to the source site to do a whitelist filtering, this is very common, using the principle of access to the B site from the A site, the HTTP protocol is supported by the Origin or Referer field, through these two fields, we can in most cases filter the non-trusted site requests.
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.
- No Origin field
- IE11 same-origin policy: IE11 does not have this field for cross-site requests, but Referer will have
- 302 redirection, because it may be thought to jump to other sites, there may be some privacy, so do not bring the source site
- Referer field
- The Referer field is an HTTP standard field, however, because the standard is not very strict, so the support of each browser varies, so there may not be
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
- In the site B form to add a CSRF_TOKEN, when you request a form in the site B, the server will create a CSRF_TOKEN for your form, and into the form, when you submit the form, while the CSRF_TOKEN will be submitted, the service first verify that there is no CSRF_TOKEN, CSRF_TOKEN is not correct so as to determine whether it is a CSRF attack.
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
- Gateway access layer: source site + whitelist filtering
- middle layer: CSRF token + verification code filtering (CSRF token can be set by cookie)
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.
- the formatting of user input to ensure that there are no special characters for the attack.
- the display of user input requires additional attention to ensure that special characters are escaped.