Common Web Security Vulnerabilities (1)

preface

XSS attack usually refers to the use of the vulnerabilities left in the development of the web page, through a clever way to inject malicious command code into the web page, the user load and execute the malicious web program made by the attacker. These malicious web programs are usually JavaScript, but can actually include Java, VBScript, ActiveX, Flash, or even plain HTML. After a successful attack, the attacker may gain various contents including but not limited to higher permissions (such as performing some operations), private web content, sessions and cookies.

A, XSS

XSS (Cross-site Scripting), just called XSS because the acronym is the same as CSS. Is a very common web attack method. The principle of XSS is that an attacker inserts malicious executable script into a Web page. When a user browses the page, the script embedded in the Web page will be executed, so as to achieve the purpose of stealing user information.

There are many ways to attack XSS, which can be roughly divided into the following types.

1. Non-persistent XSS, also known as reflective XSS

Non-persistent XSS attacks, as the name implies, are one-off attacks that affect only the currently visited page. The attacker will allow the user to access a tampered URL, and when the user accesses the link, it will trigger a script inserted into the web page, thus achieving the purpose of the attack.

https://xxx.com/xxx?test=<script>alert(document.cookie)</script>
Copy the code

For example: an attacker could execute script code alert(‘XSS’) from the above URL

2. Persistent XSS (Storage XSS)

Persistent XSS vulnerability, generally exists in form submission and other interactive functions, such as article message, text information submission, etc. Hackers take advantage of XSS vulnerability, and submit the attack script to the database for persistent storage through normal functions. When the front end page obtains the injection code read from the database by the back end, it just renders it for execution.

WeChat5a10e5ea6b59dd0198ab34d1bdee19c1.png

Compared with reflexive XSS attacks, stored XSS attacks are more persistent and harmful. But the attack cost will increase accordingly.

This is because several conditions must be met at the same time: the backend data is not escaped when it is entered into the repository. The front end gets the data and renders it without escaping it. Failure to meet any of these conditions will result in the failure of the attack.

How do I defend against XSS attacks

Start with user input

We often say that user input is not to be trusted, and think of user input as aggressive code. The most common approach is to escape input and output, such as quotes, Angle brackets, and slashes. There are many open source XSS filters out there.

Output formatting

XSS filtering for possible attacks during front-end rendering. Escape the formatting flag character to prevent execution of suspicious code. To combat XSS, the following character escapes are essential:

HttpOnly

This is the most effective defense against XSS attacks that steal user cookies. When Web applications set cookies, their attribute is set to HttpOnly, which can prevent the cookies of the Web page from being stolen by malicious JavaScript and protect the user’s cookie information.

Second, the CSRF

What is CSRF?

Cross-site Request Forgery, also known as one-click attack or Session riding, commonly abbreviated CSRF or XSRF, Is a method of hijacking a user to perform unintended actions on a currently logged Web application.

How to defend against CSRF?

CSRF attacks can be greatly reduced by following principles:

• Get requests do not modify the data
• Do not allow third-party websites to access user cookies
• Prevents third party websites from requesting interfaces
• The request is accompanied by authentication information, such as a captcha or Token

(1) SameSite

Set the SameSite property for cookies. This property indicates that cookies are not sent along with cross-domain requests and can greatly reduce CSRF attacks.

(2) Token

Add a randomly generated token as a parameter to the HTTP request, and set up an interceptor on the server to validate the token. The server reads the token value in the cookie of the current domain of the browser and checks whether the token value in the request and the cookie exist and are equal. Then the server considers the request to be a valid request. Otherwise, the request will be considered illegal and the service will be rejected.

(3) the Referer

The Referer is part of the header, and when a browser sends a request to a Web server, it usually carries the Referer information to tell the server from which page the link came, so that the server can obtain some information for processing. You can defend against CSRF attacks by checking the source of the request. The referer of normal requests has certain rules. For example, the referer of submitted forms must be the request initiated on the page. Therefore, by checking whether the HTTP header referer value is the page, we can determine whether it is a CSRF attack. But there are risks to this approach.

4) Verification code

This is a business-oriented approach that is also used on many websites. When users want to perform dangerous actions, such as changing passwords, changing mobile phone numbers, modifying bank cards, and transferring money, the second verification of the verification code can greatly improve security.

Common Web Security Vulnerabilities (2)

Reference links:

www.cnblogs.com/fundebug/p/…

zhuanlan.zhihu.com/p/163052063

Tech.meituan.com/2018/10/11/…