Common attack methods on the front end of web pages and methods to prevent attacks_HTML/Xhtml_Web page production

The security encountered in website front-end development is easily ignored by people, because most people think that these codes running in the client browser will not cause server-side security risks. This article will briefly explain the security issues often encountered in the website front-end. , and some coping strategies

With the development of front-end technology, security issues have quietly come to every user from the server, stealing user data, creating malicious self-replicating worm code, allowing viruses to spread among users, and causing the server to Dropped. What's more, users may become attackers without the user knowing it. This is definitely not shocking. The application of rich clients is becoming more and more widespread, and front-end security issues are also increasing. Today I will briefly introduce some common attack methods and methods to prevent attacks.

Common Attacks

XSS (Cross Site Script), cross-site scripting attack. It refers to a malicious attacker inserting malicious HTML code into a Web page. When a user browses the page, the embedded malicious HTML code will be executed, thereby achieving the special purpose of the malicious user. XSS is a passive attack. Because it is passive and difficult to exploit, many people often ignore its harmfulness. However, with the continuous advancement of front-end technology and the increasing number of rich client applications, this issue has attracted more and more attention. To give a simple example: If you are currently a user on the sns site, there is a vulnerability in the function of publishing information that can execute js. If you enter a malicious script at this moment, then the browsers of all people who see your new information will execute this script and a pop-up will pop up. Prompt box (very cool pop-up ads:)), if you do some more radical behavior, the consequences are unimaginable.

CSRF (Cross Site Request Forgery), cross-site forged request. As the name suggests, it allows users to use their own identity to accomplish some of the goals that the attacker needs to achieve by forging connection requests without the user's knowledge. The attack of csrf is different from that of xss csrf needs to be triggered by the attacker's active behavior. This sounds like there is a suspicion of "being fished" haha.
Multi-window browsers seem to be contributing to tyranny in this regard, because the new window opened has all current sessions. If it is a single browser window similar to IE6, there will be no such problem, because each window has is an independent process. Let’s give a simple example: You are playing White Society, and you see someone sending a link. You click on it, and then a form for sending gifts is forged in this link. This is just a simple example, and the problem is obvious.

Cookie hijacking, by obtaining the permissions of the page, write a simple request to the malicious site in the page, and carry the user's cookie. After obtaining the cookie, you can directly assume the identity of the stolen user through the cookie Log in to the site. This is cookie hijacking. To give a simple example: Someone wrote a very interesting diary and then shared it with everyone. Many people clicked to view and shared the diary. Everything seemed normal. However, the person who wrote the diary had other intentions. In the diary, A request to the outside of the site is secretly hidden in the log. Then everyone who reads this log will send their cookie to someone without knowing it, and then he can log in to this person through any person's cookie. account.

What should we do?

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

First of all, let’s talk about that as a general user of web products, many times we are passive and are exploited without knowing it. Then we can:
1 For accessing web applications with higher security levels, you need to open a separate browser window.
2 For links posted by strangers, it is best to copy them and open them in a new window. Of course, the best way is to ignore them - -.

For developers, we have to analyze it from a relatively detailed perspective:
The characteristic of XSS attacks is that the attacker’s code must be able to obtain execution permissions on the user’s browser. So where does the code come from? To prevent such attacks from happening, we can actually carry out strict filtering at the entrance and exit. With this kind of double insurance, it should be said that 99% of similar problems have been solved by us, and the other 1% is the sequelae caused by those crappy browsers. , I believe that this kind of problem will become less and less in the future.

Here I have sorted out the forms of xss vulnerabilities

The malicious code value is displayed as the content of a certain tag (if the input is html, the html will be parsed). For example, after you enter the user name and update it, the user name will be displayed in a certain tag on the page. If you enter

popper.w

So if it is displayed directly on the page without filtering, a third-party js code will be introduced and executed.

Strategy: Filter html tags and some special characters (" < > &, etc.) where HTML input is not required, and convert them into characters that are not interpreted and executed by the browser

Malicious code is displayed as an attribute of a certain tag (by using " to truncate the attribute to open up new attributes or malicious methods). This situation is often caused by developers who may record some information on certain DOM tags in order to implement functions. The information entered by the user, such as the user name you enter, will appear in the form of title in the tag on the page. If you enter carefully designed content, then take a look at this

popper.w" onclick="alert(1)

What I actually entered here is "popper.w" onclick="alert(1)", of course you can write more content above.

Strategy: Filter some characters that may be truncated in the attribute. Single quotes and double quotes that exist in the attribute itself need to be transcoded.

The malicious code is displayed as the html code itself (common html editor). This situation has the most problems, so I won’t give an example here.

Strategy: It is best to whitelist filter the html tags and tag attributes entered by the user. You can also perform special filtering on some vulnerable tags and attributes.

The malicious code is displayed as a json string (creating new malicious js variables or even executable code through variable truncation). The key to this problem is that the information entered by the user may become part of the js code in the page.

Strategy: Filter some characters that may be truncated in the attribute. Single quotes and double quotes that exist in the attribute itself need to be transcoded.

For crsf and cookie hijacking

Features: High concealment. Sometimes, xss vulnerabilities are exploited first and then deceived

Strategy
Detect user submissions through referer, token or verification code.
Try not to reveal any information related to the user’s unique number (user ID) in the link on the page.
For user modification, deletion and submission operations, it is best to use the post operation.
Avoid site-wide cookies and set cookies strictly for the domain.

ok I’ll just write it here~

The above are some common security issues, mainly from the perspective of js hack. With the continuous development and progress of front-end technology, more security issues may appear in front of us. For developers, Most problems can be avoided during the development stage, so the scary thing is not hacks. What is scary is our laxity in the security of our products~.