CSRF Attack: Cross-Site Request Forgery
Attackers steal your identity and send malicious requests in your name, which can easily lead to leakage of personal privacy and property safety.
Reason: SRF attack originates from WEB's implicit authentication mechanism! Although the authentication mechanism of the WEB can guarantee that a request is from a user's browser, it cannot guarantee that the request is sent with the approval of the user.
Object of attack: All the attacker can do is to send a request to the server to execute the command described in the request, and directly change the value of the data on the server side, rather than stealing the data in the server. Therefore, the objects we want to protect are those services that can directly generate data changes, and for services that read data, CSRF protection is not required. For example , GET requests do not need CSRF protection. Querying the balance is a read operation of the amount, which will not change the data. CSRF attacks cannot parse the results returned by the server (due to the limitation of the browser's same-origin policy, hackers cannot parse it), and no protection is required.
How to defend:
Verification code: The process of CSRF attack often occurs without the user's knowledge. Network requests are constructed without the user's knowledge. Therefore, if a verification code is used, each operation requires user interaction, which is simple and effective. It can effectively defend against CSRF attacks. The verification code generally only appears in special operations, or is used during registration. More seriously affect the user experience.
Detecting Referer: According to the HTTP protocol, there is a field called Referer in the HTTP request header, which records the source address of the HTTP request. Under normal circumstances, a 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. If the Referer is another website, it may be a hacker's CSRF attack and reject the request. The obvious advantage of this method is that it is simple and easy to implement. Ordinary developers of the website do not need to worry about CSRF vulnerabilities. They only need to add an interceptor to to check the value of Referer.
Disadvantages: Each browser may have different implementations of Referer, and there is no guarantee that the browser itself has no security holes (some referer values can be tampered with). In addition, the Referer value will record the source of the user's visit. Some users think that this will violate their own privacy. Users can set their browser to not provide Referer when sending requests.
Token: The current mainstream approach is to use Token to defend against CSRF attacks.
The condition for a successful CSRF attack is that the attacker can accurately predict all parameters to construct a legitimate request. Therefore, according to the principle of unpredictability, we can encrypt the parameters to prevent CSRF attacks, and keep the original parameters unchanged. In addition, add a parameter Token whose value is random, so that the attacker cannot construct a legitimate request to attack because he does not know the Token, so we only need to ensure that when constructing the request:
The Token should be random enough so that the attacker cannot accurately predict that
the Token is one-time, that is, the Token should be updated after each request is successful, which increases the difficulty of prediction
Note: Filtering user input does not prevent CSRF attacks , what we need to do is filter the source of the request, because some requests are legal and some are illegal. Therefore, CSRF defense is mainly to filter out those illegally forged request sources.
XSS attack (cross-site scripting attack)
Principle: The attacker enters malicious HTML code into a website with XSS vulnerabilities. When other users browse the website, the HTML code will be automatically executed, so as to achieve the purpose of the attack, such as stealing the user's cookie, destroying the page structure, Redirects to other websites, etc.
the comment function of a forum does not filter XSS, then we can comment on it
alert('You can't turn me off');
If the content text of JS is included in the post comments, if the server does not filter or escape these scripts and post them on the page as content, other users will run this script when they visit the page. Malicious code can also be posted to steal your cookies or other information.
How to defend: filter user input / escape user input.