XSS and CSRF attack defense

XSS

What is XSS?

XSS is a cross-site scripting attack, which is due to poor handling of user input, resulting in malicious scripts being executed in the browser

Classification of XSS

Reflected XSS

The user enters data through the page input box, and submits the data to the server through the get or post method. The input data generally exists in the query string of the URL or the submitted form, and the server does not check, filter, or encode the input data, and directly Presenting the data entered by the user may cause XSS attacks. Hackers generally construct a URL containing XSS codes, induce users to click, trigger XSS codes, and achieve the purpose of hijacking access and obtaining cookies.

Persistent XSS

Usually, the server saves the input malicious script into the database without verification, and displays the data on the browser by calling the database. When the page is opened, the malicious script is executed. Whenever the user opens the page, the malicious script is executed.

example

A comment feature where hackers enter malicious code

 The background is saved to the database, and these malicious attack codes will be executed when other users view comments

 DOM-type XSS

It is the XSS inserted by modifying the DOM node. In fact, the front-end code is not rigorous enough and untrustworthy content is inserted.

How to defend against XSS?

1. Use XSS Filter

   Validate against user-entered data

•  Specify the input length, other content will be filtered out
• The type of value specified in the form, for example, age can only be a number, and the name can only be a string
• Filter out special html tags: <script>, <iframe>, etc.
•  Tags for filtering js events: onclick, onerror, onfocus, etc.

 2. HTML entities

    escape special characters

 3. Http Only cookie

 Mark the cookie as http only, so that when the browser makes a request to the server, it will bring the cookie field, but the cookie cannot be accessed in the script

CSRF

CSRF stands for Cross Site Request Forgery

attack principle

1. User A opens a browser, visits trusted website B, and enters user name and password to log in to website B
2. After the user information is verified, B will generate and return cookie information to the browser. At this time, user A has successfully logged in and can send requests to B normally.
3. In order to exit website B, the user visits website C in the same browser
4. After receiving the user request, website C returns some offensive codes and initiates a request to visit the third website B
5. After the browser receives these offensive codes, according to C's request, it will carry cookie information to initiate a request to website B without the user's knowledge. B does not know that the request is initiated by C, so it will use A's cookie information to User A's permission processing request finally causes C's malicious code to be executed in B

CRSF prevention

1. Verify the HTTP Referer field

According to the HTTP protocol, there is a field called Referer in the HTTP header, which records the source address of the HTTP request. Under normal circumstances, the request to access a security-restricted page comes from the same website. For example, to access http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory, the user must first log in to bank.example, and then pass Click the button on the page to trigger the transfer event. At this time, the Referer value of the transfer request will be the URL of the page where the transfer button is located, which usually starts with the bank.example domain name. And if a hacker wants to implement a CSRF attack on the bank's website, he can only construct a request on his own website. When a user sends a request to the bank through the hacker's website, the Referer of the request points to the hacker's own website. Therefore, to defend against CSRF attacks, the bank website only needs to verify the Referer value for each transfer request. If the domain name starts with bank.example, it means that the request is from the bank website itself and is legal. If the Referer is another website, it may be a hacker's CSRF attack, and the request is rejected.

        The obvious advantage of this method is that it is simple and easy to implement. Ordinary website developers don't need to worry about CSRF vulnerabilities. They only need to add an interceptor to all security-sensitive requests at the end to check the Referer value. Especially for the current existing system, there is no need to change any existing code and logic of the current system, there is no risk, and it is very convenient.

        However, this method is not foolproof. The value of Referer is provided by the browser. Although there are clear requirements in the HTTP protocol, each browser may have different implementations of Referer, which does not guarantee that the browser itself has no security holes. Using the method of verifying the Referer value is to rely on the third party (ie the browser) to ensure the security. In theory, this is not safe. In fact, for some browsers, such as IE6 or FF2, there are already some methods to tamper with the Referer value. If the bank.example website supports the IE6 browser, the hacker can completely set the Referer value of the user's browser to an address starting with the bank.example domain name, so that it can pass the verification and conduct CSRF attacks.

Even with the latest browsers, hackers cannot tamper with the Referer value, and this method is still problematic. Because the Referer value will record the user's access source, some users think that this will violate their own privacy, especially some organizations worry that the Referer value will leak some information from the organization's intranet to the external network. Therefore, users can set their browsers to no longer provide Referer when sending requests. When they visit the bank website normally, the website will consider it a CSRF attack because the request does not have a Referer value, and deny access to legitimate users.

2. Add token to the request address

 The reason why the CSRF attack can be successful is that the hacker can completely forge the user's request, and all the user authentication information in the request exists in the cookie, so the hacker can directly use the user's own cookie without knowing the authentication information to pass security verification. To resist CSRF, the key is to put information in the request that hackers cannot forge, and this information does not exist in the cookie. A randomly generated token can be added as a parameter in the HTTP request, and an interceptor can be established on the server side to verify the token. If there is no token in the request or the content of the token is incorrect, it is considered that it may be a CSRF attack and the request is rejected .

        This method is safer than checking the Referer. The token can be generated and placed in the session after the user logs in, and then the token is taken out of the session at each request and compared with the token in the request, but this The difficulty of this method is how to add the token to the request as a parameter. For GET requests, the token will be appended to the request address, so that the URL becomes http://url?csrftoken=tokenvalue. For POST requests, add <input type=”hidden” name=”csrftoken” value=”tokenvalue”/> at the end of the form, so that the token is added to the request as a parameter. However, in a website, there are many places where requests can be accepted. It is very troublesome to add a token to each request, and it is easy to miss. The usual method is to use javascript to traverse each time the page loads For the entire dom tree, add token after all a and form tags in the dom. This can solve most of the requests, but for the html code dynamically generated after the page is loaded, this method has no effect, and the programmer needs to manually add the token when coding.

         Another disadvantage of this method is that it is difficult to guarantee the security of the token itself. Especially in some forums and other websites that support users to publish their own content, hackers can publish the address of their own personal website on it. Since the system will also add a token after this address, hackers can get this token on their own website and launch CSRF attacks immediately. In order to avoid this, the system can add a judgment when adding the token. If the link is linked to its own site, add the token later, and not add it if it leads to the external network. However, even if the csrftoken is not attached to the request as a parameter, the hacker's website can also get the token value through Referer to launch CSRF attacks. This is why some users like to manually turn off the browser Referer function.

3. Customize attributes in the HTTP header and verify

 This method also uses the token and performs verification. The difference from the previous method is that the token is not placed in the HTTP request as a parameter, but placed in a custom attribute in the HTTP header. Through the XMLHttpRequest class, you can add the HTTP header attribute csrftoken to all requests of this type at one time, and put the token value into it. This solves the inconvenience of adding the token to the request in the previous method. At the same time, the address requested through XMLHttpRequest will not be recorded in the browser's address bar, and there is no need to worry about the token being leaked to other websites through the Referer.

        However, this method is very limited. XMLHttpRequest request is usually used in Ajax method for partial asynchronous refresh of the page, not all requests are suitable for this class to initiate, and the page obtained through this type of request cannot be recorded by the browser, so as to move forward, back and refresh , Favorites and other operations will cause inconvenience to users. In addition, for legacy systems that do not have CSRF protection, to use this method for protection, all requests must be changed to XMLHttpRequest requests, which will almost rewrite the entire website, which is undoubtedly unacceptable.

4. Add verification code for important website operations

Reference from XSS and CSRF attack defense_zl's blog - CSDN blog