Detailed introduction to front-end security and how to prevent it

With the development of the Internet, various WEB applications have become more and more complex to meet the various needs of users, but with them come various network security issues. As a front-end development industry, we cannot escape this problem. So today I will briefly talk about WEB front-end security and how to prevent it.

First of all, what are the forms of front-end attacks and how should we prevent them?

1. XSS attack

XSS is a A computer security vulnerability that often occurs in web applications that allows malicious web users to insert code into pages that are available to other users. For example, these codes include HTML code and client-side scripts. Attackers use XSS vulnerabilities to bypass access control - such as the same-origin policy (same origin policy). This type of vulnerability has become widely known as it is used by hackers to write more harmful phishing (Phishing) attacks.

The hazards of XSS attacks include:

1. Stealing various user accounts, such as machine login accounts, user online banking accounts, and various administrator accounts

2. Control Enterprise data, including the ability to read, tamper with, add, and delete sensitive enterprise data

3. Theft of important enterprise information with commercial value

4. Illegal transfers

5. Forced to send emails

6. Website hanging horse

7. Control the victim machine to launch attacks on other websites

Specific manifestations of XSS attacks:

　1. JavaScript code injection

The following is the code page:

The function of this code is to insert the string in the first input box. Output to the second input box, we enter 1, then the value in the second input is 1. Below are screenshots of the page and source code (here I enter the following code to test)

<SCRIPT>alert(&#39;xss&#39;)</SCRIPT>

It can be clearly seen that there is no pop-up dialog box. You may wonder why there is no pop-up window. Take a look at the source code

We see that the string we entered is output to the value attribute in the input tag on line 15, and is displayed as the value in value, so there is no pop-up window. At this time What should we do? Smart people have discovered that you can add a "> in front of

<SCRIPT>alert(&#39;xss&#39;)</SCRIPT>

to close the input tag. So the result you should get is

The window pops up successfully, we are looking at the page at this time

We see that there is a second input input box followed by "> string, Why is this happening? Let’s take a look at the source code.

Solution: At present, the simplest prevention method is to escape all the front-end output data. Safe, although it is shown that there is a script tag, in fact, the left and right angle brackets (><) of the script tag are escaped into HTML character entities, so they will not be parsed as tags, but When actually displayed, these two angle brackets can still be displayed normally.

2. Utilization of append

In the previous section, we guarded against the left and right angle brackets of the script tag, but smart hackers still figured out a good way to crack it. We know that, just give Assigning a piece of js to innerHTML cannot be executed. For example,

<br/>

However, jQuery’s append can do this. The reason is because jquery will find the script tag in it when changing the append element into a fragment, and then use eval to execute it again. The method used by jquery's append is also innerHTML. InnerHTML will convert unicode codes into character entities.

Using the combination of these two kinds of knowledge, we can conclude that the website uses append to perform dom operations. If it is a field that we can determine in append, then we can disguise the left and right angle brackets using unicode code, like this-- "\u003cscript\u003ealert('xss');". When escaping next, the

3. Reuse of the img tag

The img tag will call onerror on the element when loading the image fails. event. This is how we can attack.

But what if we write the address of this picture differently?

The source code at this time has changed For --src is empty, but when onerror occurs, the injected code is executed. When we refresh the page, we will find that the code injection has been successful and needs to continue to be escaped.

2. CSRF attack

What is a CSRF attack?

　CSRF(Cross-site request forgery Cross-site request forgery, also known as "One Click Attack" or Session Riding, usually abbreviated as CSRF or XSRF, is a malicious use of the website. In fact, some submission behaviors in the website are used by hackers. When you visit the hacker's website, The operations performed will be operated on other websites (such as the website of the online bank you are using).

1. Use post and get reasonably. Usually we will do it to save trouble. , make some data that should be submitted into a get request. As everyone knows, this not only violates the standards of http, but can also be used by hackers.

For example, in the website you develop, there is a The operation of purchasing goods. You developed it like this:

# Then, the hacker’s website can be developed like this:

In this case, the user only needs to visit the hacker's website once, which is actually equivalent to operating once on your website. However, the user has no perception.

So, in our daily development, we still have to follow the submission business and strictly follow the post request. Don't use jsonp to make submission interfaces, which is very dangerous.

2. xsrf attack Upgrade

If you use post requests to handle key business, there are still ways to crack it. Our business code is as follows:

The hacker code is as follows:

After clicking, the user submitted without even knowing it. How to defend against this situation?

The simplest way is to add a verification code, so that apart from the user, the hacker's website cannot obtain the user's verification code for this session. However, this will also reduce the user's submission experience, especially for some frequent operations. If the user is always asked to enter the verification code, the user will be very annoyed.

Another way is to plant the verification token in the pages visited by the user, and all submissions by the user must be brought The token generated in this page is essentially the same as using a verification code. However, in this way, the same token can be used for every session on the entire page. For many post operations, developers can automatically bring the current The token of the page. If the token verification fails, it proves that the submission is not sent from this site, and the submission process is terminated. If the token is indeed generated for this website, it can pass.

The code is as follows

does not carry the token generated by each session of this site, so the submission fails.

The website form of this site will automatically carry the token generated by this site

If you use the webpage of this site to submit again, you will use

Of course, the above are just examples. The specific token generation must change with the session and user ID. If you feel that your website also needs to add a token, please Baidu for in-depth study. .

Many times, our website does not directly access our server, but passes through many layers of proxies. If at a certain link, the data is intercepted by hijackers at the intermediate proxy layer, they can obtain it. Confidential data such as passwords for users of your website. For example, our users often connect to some weird wifi in various restaurants. If this wifi is a hotspot wifi established by a hacker, then the hacker can access all the data sent and received by the user. Here, it is recommended that webmasters use https for encryption on their websites. In this way, even if the website data can be obtained, hackers cannot decrypt it.

The above is the detailed content of Detailed introduction to front-end security and how to prevent it. For more information, please follow other related articles on the PHP Chinese website!