Common attacks on web front-ends and ways to prevent them

The security issues encountered in website front-end development are easily overlooked by people, because most people believe that these codes running on the client browser will not cause security risks on the server side. This article will briefly explain the security issues that are often encountered in the front-end of the website, as well as some coping strategies

With the development of front-end technology, security issues have quietly moved from the server to every user, stealing user data, creating malicious self-replicating worm codes, allowing viruses to spread among users, and crashing servers. What's more, users may become attackers without their knowledge, which is definitely not shocking. As rich clients are increasingly used, front-end security issues are also increasing. Today, we will briefly introduce some common attack methods and ways to prevent them.

Common attacks

XSS (Cross Site Script), cross-site scripting attack. It refers to malicious attackers 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 malicious user's special purpose. XSS is a passive attack. Because it is passive and difficult to use, many people often ignore its harmfulness. However, with the continuous advancement of front-end technology and the increasing number of rich client applications, issues in this area are receiving more and more attention. Let's take a simple example: If you are a user on an SNS site, and there is a vulnerability in the information publishing function that allows the execution of JS. If you enter a malicious script at this moment, then the browsers of all people who currently see your new information will execute this script and a prompt box will pop up (pop-up ads are cool, right? :)). If you do something more radical, the consequences will be unimaginable.

CSRF (Cross Site Request Forgery), cross-site forged request. As the name suggests, it is to forge connection requests without the user's knowledge, so that the user can use his or her own identity to complete some of the goals that the attacker needs to achieve. CSRF attacks are different from XSS attacks in that CSRF needs to be triggered by active behavior of the attacker. This sounds like a case of being phished, haha.
Multi-window browsers seem to be aiding and abetting in this regard, because the new window opened has all the current sessions. If it is a single browser window like IE6, there will be no such problem, because each window is an independent process. Let's take a simple example: you are playing Baishehui, and you see someone sent a link. You click on it, and then there is a fake gift-sending form in the 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 log in to the site directly as the stolen user through the cookie. This is cookie hijacking. Let's take a simple example: Someone wrote an interesting blog post and shared it with everyone. Many people clicked on it to view and share it. Everything seemed normal. However, the person who wrote the blog post had other intentions and secretly hid a request to an external site in the blog post. Then, everyone who had read the blog post would unknowingly send their cookies to someone else, and he could log in to anyone's account through that person's cookie.

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 how, as a general user of web products, we are often passive and are exploited without knowing it. Then we can:
1 To access web applications with a higher security level, 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 need to analyze from some relatively detailed perspectives:
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, you can actually perform strict filtering at the entrance and exit. This double insurance should mean that 99% of similar problems have been solved by us. The other 1% are the sequelae brought about by those crappy browsers. I believe that such problems 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, if you enter a username, the username will be displayed in a certain tag on the page after the update. If you enter

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

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 tag (by using " to truncate the attribute to create a new attribute or malicious method). This situation is often because developers may record some user input information on certain DOM tags in order to implement functions. For example, the username you enter will appear as a title in the tag on the page. At this time, if you enter carefully designed content, then look at this

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

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

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

Malicious code is displayed as HTML code itself (common HTML editors). This situation has the most problems, so I will not give an example here.

Strategy: It is best to whitelist the HTML tags and tag attributes entered by users, or to specifically filter some tags and attributes that have vulnerabilities.

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 out some characters that may be truncated in the attribute. Both single and double quotes in the attribute itself need to be transcoded.

For crsf and cookie hijacking

Features: Highly concealed. Sometimes, the XSS vulnerability is exploited first and then the deception is done.

The strategy checks user submissions via referer, token, or verification code.
Try not to expose any information related to the user's unique number (user ID) in the link on the page.
It is best to use post operations for user modification, deletion and submission operations.
Avoid site-wide cookies. Be strict about the domain that sets cookies.

Ok, I'll stop here~

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