In the world of Web security, XSS and CSRF are the most common attacks. This article will briefly introduce the attack and defense issues of XSS and CSRF.
Cross Site Script (XSS) attacks
XSS attack refers to an attack in which an attacker injects malicious client code into a website and tamper with the client web page through malicious scripts, so as to control the user’s browser or obtain the user’s private data when browsing the web page.
The malicious scripts that attackers inject into client web pages typically include JavaScript, but sometimes HTML and Flash. There are many ways to conduct AN XSS attack, but what they all have in common is: sending some private data like cookies and sessions to the attacker, redirecting the victim to a website controlled by the attacker, and performing some malicious operations on the victim’s machine.
XSS attacks fall into three categories: reflective (non-persistent), storage (persistent), and DOM-based.
XSS is mainly through the input box form of SUBMITTING JS script, and finally on the page to be executed.
Defending against XSS attacks
Mainstream browsers now have built-in protection against XSS, such as CSP. But developers should also look for reliable solutions to prevent XSS attacks.
HttpOnly Prevents Cookie hijacking
HttpOnly was first proposed by Microsoft and has become a standard. The browser will disable the page’s Javascript from accessing cookies with the HttpOnly attribute.
As mentioned above, an attacker can obtain a user’s Cookie information by injecting malicious scripts. Generally, cookies contain the login credentials of users. After obtaining cookies, attackers can launch Cookie hijacking attacks. So, strictly speaking, HttpOnly does not prevent XSS attacks, but rather prevents Cookie hijacking attacks after XSS attacks.
Input inspection
Don’t trust any input from the user. Any input from the user is checked, filtered, and escaped. Create a whitelist of trusted characters and HTML tags and filter or encode characters or tags that are not included in the whitelist.
In XSS defense, input check is to check whether the data entered by the user contains special characters such as <, >. If there are special characters, special characters are filtered or encoded. This method is also called XSS Filter.
In some front-end frameworks, there is a decodingMap that encodes or filters special characters or tags in user input, such as <, >, script, to prevent XSS attacks:
// In vuejs, if you input a script tag, it will filter out const decodingMap = {'< ': '<'.'> ': '>'.'" ': '"'.'& ': '&'.'& # 10; ': '\n'
}
Copy the codeOutput check
There will be problems with the input from the user and problems with the output from the server. In general, with the exception of rich text output, you can encode or escape variables when they are output to HTML pages to defend against XSS attacks. For example, you can use sanitize-HTML to filter the output and then output it to the page.
CSRF (Cross Site Request Forgery)
CSRF, or Cross Site Request Forgery, is an attack that hijacks a trusted user to send an unexpected Request to a server.
In general, CSRF attack is an attack in which the attacker obtains the trust of the server with the help of the victim’s Cookie. The attacker can forge a request in the victim’s name and send it to the attacked server without the victim’s knowledge, so as to perform the operation under the protection of permission without authorization.
On the premise that the user has logged in to the target site and visited the phishing website of the attacker, the attacker directly calls the interface of the target site through the URL and conducts attacks by forging the user’s behavior, which is usually unknown to the user.
Defense against CSRF attacks
Currently, the defense measures against CSRF attacks are as follows:
Verification code
Captcha is considered as the most concise and effective defense against CSRF attack.
As you can see from the above examples, CSRF attacks often construct network requests without the user’s knowledge. The captcha forces the user to interact with the application in order to complete the final request. In general, captcha is a good deterrent to CSRF attacks.
But the verification code is not omnipotent, because for user consideration, can not give the site all the operation with verification code. Therefore, verification code can only be used as an auxiliary means to defend against CSRF, but not as the primary solution.
Referer Check
According to the HTTP protocol, there is a field in the HTTP header called Referer, which records the source address of the HTTP request. The Referer Check lets you Check whether a request is coming from a legitimate “source.”
For example, if a user wants to delete a post, he or she must first go to www.c.com, then go to the corresponding page and initiate a deletion request. In this case, the Referer value is www.c.com; When a request is initiated from www.a.com, the Referer value is www.a.com. Therefore, to defend against CSRF attacks, only the Referer value needs to be verified for each post deletion request. If the domain name starts with www.c.com, it indicates that the request comes from the website itself and is legal. If Referer is another site, it could be a CSRF attack and the request can be rejected.
For the above example, you can add the following code on the server:
if(req.headers.referer ! = ='http://www.c.com:8002/') {
res.write('CSRF attacks');
return;
}
Copy the codeNot only does Referer Check protect against CSRF attacks, another application scenario is to “prevent image piracy”.
Adding token authentication
The CSRF attack is successful because the attacker can completely forge the user’s request, and all the user authentication information in the request is in the Cookie. Therefore, the attacker can directly use the user’s own Cookie to pass the security authentication without knowing the authentication information. The key to defending against CSRF is to put information in the request that the attacker cannot falsify, and that information does not exist in the Cookie. A randomly generated token can be added to the HTTP request in the form of a parameter, and an interceptor can be set up on the server side to verify the token. If there is no token in the request or the token content is incorrect, the request may be rejected as a CSRF attack.
conclusion
This paper mainly introduces the attack principle and defense measures of XSS and CSRF. Of course, in addition to these two common attacks in the Web security world, there are other attacks, such as SQL injection, that are beyond the scope of this article, but if you are interested in them, read the SQL Injection technology column for more information. Finally, a summary of common defenses against XSS and CSRF attacks:
- Defend against XSS attacks
- HttpOnly Prevents Cookie hijacking
- Check the user’s input
- Check the output of the server
- Defend against CSRF attacks
- Verification code
- Referer Check
- Token authentication