Front-end security problems

Common attacks

XSS (Cross Site Script.A malicious attacker inserts malicious html code into a Web page. When a user browses this page, the embedded malicious html code is executed to achieve the Special Purpose of malicious users. XSS is a passive attack, because it is passive and not easy to use, so many people often call it harmful. However, as the front-end technology continues to improve, rich clients are increasingly used, and this issue is becoming increasingly concerned. For example, if you are a user on the sns site, the vulnerability in the information publishing function can execute javascript. You can enter a malicious script at the moment, then all browsers that see your new information will execute this script to bring up a prompt box (it is nice to bring up an advertisement :)). If you do more radical actions, the consequences are unimaginable.

CSRF (Cross Site Request Forgery), Cross-Site Forgery Request.As the name suggests, the attacker needs to achieve some goals by forging connection requests without the user's knowledge. Csrf attacks are different from xss csrf attacks that need to be triggered by an attacker's active behavior. This seems to be suspected of "phishing.
Multi-Window browsers seem to be suspected of abuse in this regard, because the new window opened has all the current sessions. If it is a single browser window similar to ie6, there will be no such problem, because each window is an independent process. For example, you are playing in the white community. When someone sends a connection, you click it. Then, the connection spoofs a gift form. This is just a simple example, the problem is common.

Cookie hijacking by obtaining page Permissions, Write a simple request to a malicious site in the page, and carry the user's cookie to obtain the cookie, then the cookie can be directly logged on to the site as a stolen user. This is cookie hijacking. For example, someone wrote an interesting log and shared it with everyone. Many people click to view and share the log. Everything seems to be normal, however, the log writer uses another intention to Secretly hide a request outside the site in the log, then, all the people who have read this log will send their cookies to someone without their knowledge. Then, they can log on to this person's account through the cookies of any person.

What should we do?

It can be roughly divided into two categories: 1. General users and 2. website developers.

First of all, as a general web product user, we are often passive and used without knowledge. Then we can:
1. An independent browser window is required for web application access with higher security levels.
2. The best way to copy a link published by a stranger and open it in a new window is to ignore --.

For developers, we need to analyze from a relatively detailed perspective:
Xss attacks are characterized by the fact that the attacker's code must be able to obtain the execution permission on the user's browser. Where does the Code come from, if you want to prevent such attacks, you can strictly filter them at the entrance and exit. Such a double insurance solution should address a 99% similar problem, the other 1% is the consequence of poor browsers, and I believe this problem will become fewer and fewer in the future.

Here I have sorted out the form of xss vulnerabilities

The malicious code value is displayed as the content of a tag (html will be parsed if html is entered) for example, if you enter a user name, the updated user name will be displayed in a tag on the page.

Popper. w <script src = "hack. js" type = "text/javajscript"> </script>

If the page is directly displayed without filtering, a third-party js Code will be introduced and executed.

Policy: filter html tags and special characters ("<>& etc.) without html input to convert them into characters not interpreted by the browser.

Malicious Code is displayed as an attribute of a tag (new attributes or malicious methods are opened by "truncation of attributes) in this case, the developer may record some user input information on some dom labels to implement the function. For example, the user name you enter will appear in the form of title in the tag on the page. If you entered well-designed content, so let's take a look at this

<A title = "popper. w" onclick = "alert (1)"> popper. w "onclick =" alert (1) </a>

Here I actually input "popper. w" onclick = "alert (1)". Of course you can write more content on it.

Policy: filter certain characters in the attribute that may be truncated. The single quotation marks and double quotation marks in the attribute must be transcoded.

Malicious Code is displayed as html code itself (Common html editor), which has the most problems. Here is an example.

Policy: It is recommended that you perform whitelist filtering on html tags and tag attributes entered by the user, or specifically filter tags and attributes with vulnerabilities.

Malicious Code is displayed as a json string (using variable truncation to create malicious js variables or even executable code) the key to this problem is that the information entered by the user may become part of the js Code on the page.

Policy: filter certain characters in the attribute that may be truncated. The single quotation marks and double quotation marks in the attribute must be transcoded.

Crsf and cookie hijacking

Features are relatively concealed. In some cases, xss vulnerabilities are used before spoofing.

Policy
You can use referer, token, or verification code to detect user submissions.
Do not expose any information related to the user's unique ID (User ID) in the link of the page.
It is best to use the post operation to modify, delete, and submit operations.
Avoid strictly setting the cookie domain for all common site cookies.

OK, write it here ~

The above are some common security issues, mainly from the js hack aspect. As the front-end technology continues to develop and improve, more security problems may be shown in our face, for developers, most of the problems can be avoided in the development phase, so what's terrible is that we are lax in our product security ~.