Common webpage front-end attack methods and methods to prevent attacks _ HTML/Xhtml _ webpage Creation

Discusses the security of website front-end development. the security of front-end website development is easily overlooked, because most people think that the code running on the client browser will not cause security risks on the server, this article will briefly describe the security problems frequently encountered in the front-end of the website and some countermeasures.

With the development of front-end technology, security issues have quietly come to every user from the server, stealing user data, creating malicious worm code that can be self-copied, and spreading viruses among users, disable the server. what's more, users may become attackers without being aware of them, which is definitely not shocking. Rich clients are widely used, and front-end security problems are also increasing. Today, we will briefly introduce some common attack methods and attack prevention methods.

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