Took a closer look at XSS attacks recently. It was always superficial to think that XSS defense was just the XSS that input filtering could create. But the pool is very deep.

1. Type of XSS

Generally speaking, XSS can be divided into three types: storage TYPE XSS, reflection type XSS and DOM-XSS.

1.1 Storage TYPE XSS

Data that exists in the database for XSS attacks is returned to the client. If the data has not been escaped. Rendered by the browser. Can lead to XSS attacks;

1.2. Reflective XSS

Data entered by users with XSS attacks is sent to the background. The background does not store the data or filter the data and directly returns it to the client. Rendered by the browser. Can lead to XSS attacks;

1.3, DOM – XSS

XSS attacks that are purely client-side, such as:

www.some.site/page.html?d…

Page code:

... Select your language:

<select>
    <script> 
        document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</OPTION>");  

        document.write("<OPTION value=2>English</OPTION>");    

    </script>

</select> 

...Copy the code

Implementation conditions of the XSS attack:

  1. The user clicked the following link:

    http://www.some.site/page.html?default=<script>alert(document.cookie)</script>Copy the code

  2. The background does not filter URL parameters and returns them to the client. The front end directly obtains parameters from the URL.

  3. The browser that opens the url is an earlier version, usually ie8 or less

Meeting the above three will cause js code on the URL to execute :alert(document.cookie), but attackers can use this to do things you can’t imagine. In modern browsers, XSS filtering is already done. If XSS is detected, the following error message is displayed:

The XSS Auditor refused to execute a script in 'file:///C:/Users/summerhxji/Desktop/taobao/xss.html? default=%3Cscript%3Ealert(document.cookie)%3C/script%3E' because its source code was found within the request. The auditor was enabled as the server did not send an 'X-XSS-Protection' header. (anonymous) @ xss.html? default=<script>alert(document.cookie)</script>Copy the code

The above is the academic classification of XSS attack types, type 2 and type 3 are actually reflex attacks. Knowing this, realize that XSS attacks are everywhere.

So how do you defend against XSS?

Both input and output need to be filtered and escaped.

XSS defense – input/output filtering and data escape

2.1 input

Client parameters: include user input, URL parameters, and POST parameters.

  1. In terms of product form, variable types are restricted for different input types. For example, http://xss.qq.com?default=12, the Default value is an integer. We have node in the background and use joI to restrict the input type:

    const { default } = req.body;

    const schema = Joi.number().required();

    const result = schema.validate(default);

    if(result.error) {
....
}Copy the code

  2. String data needs materialized escape for <, >, /, ‘, “, and & characters.



2.2 the output

Even if the user’s input is filtered or escaped on the client side, an attacker can modify the body of your request packet by means of packet cutting and forwarding. Ultimately, you have to do data escape at data output time.

<>, ‘& “materialized escape. If you think it’s that easy, NO, NO, NO… Because the encoding of HTML and JS in browser parsing is different, as well as the context of various scenarios, the transcoding of variables output in the background is different from the rendering of back-end variables in different contexts.

The following HTML snippet shows how to safely render untrusted data in many different contexts.


All output data escapes should follow the rules in the table above, but there are major differences in use for synchronous and asynchronous data:

  1. Synchronize data a. The React page actively shields XSS. Non-react needs to escape untrusted data. B. For HTML whitelist requirements, the SanitizeHelper module provides a collection of methods to handle unexpected HTML elements. C. Different use methods, different encoding methods, Java ready-made tools can be used — ESAPI, different locations how to escape can refer to ESAPI documentation, such as attribute value escape:

    String safe = ESAPI.encoder().encodeForHTMLAttribute( 
request.getParameter( "input" ) );Copy the code

  2. Asynchronous, background direct json data to JS for untrusted JSON data. Because JSON data can be used in different places, escapes can be placed in front-end JS to escape. A. It is better to convert the dynamic variables involved in the operation into corresponding types before operation. B. If the operation is a string operation, ensure that the string is enclosed in quotation marks. C. Do not use eval, new fuction, or setTimeout to execute a dynamic string, because the string is probably XSS code and should be escaped if necessary. D. The data output to the page must be escaped using the corresponding method, and the front-end can consider looking for JS plug-ins for processing. Currently jQUERy-Encoder can be used for front-end JSON escape. It is used in a similar way to ESAPI, escaping when rendering is required.

The front end XSS defense scheme looks like this, with so much dry stuff sorted out that I, as a small front end, would absorb it for a few days.

3. Case sharing

Finally, in addition to the XSS attack above, I will share with you one more security vulnerability that you might not expect in the real world.

In the best beta project, early development environment, our testers proposed the following security vulnerabilities:

As for the login page below, we added a service parameter to the URL in order to enable users to access the page they visited before after logging in, but did not make any verification on it, which may be used by phishing websites.

The attack conditions are as follows:

  1. Users to click on the following link: https://cas.utest.qq.com/qqlogin?service=http%3A%2F%2Fpianzi.com;

  2. Service parameters are not verified at the back end, so the connection can be redirected to the page above.

  3. After logging in to pianzi.com, the user enters an account and goes to pianzi.com.

  4. This is a phishing site, through the site style deception, for users to guide the operation;

  5. The user enters some useful information;

  6. Unknowingly, users give away their information.

What a deep routine ah ~~ r & D brother to find a solution.

The final confirmation scheme is as follows: Whitelists forward IP addresses after login.

As for the old XSS attack, WEB developers only know one thing. Kids from the front end know very little about it, and there are many students like me who have little awareness of it. As a lazy person, I want to find a way to do everything once and for all, but for XSS attacks, they are everywhere and there is no good global solution. Front-end kids know more about the general XSS attack, when the code has this attack awareness, is also very good.

There are many aspects of front-end security that need to be understood, from preventing CSRF attacks to enabling modern browser security defenses.

End of topic, push a hard AD:

If you are front-end development, Tencent excellent test H5 test is absolutely your development good assistant, improve the development efficiency that is a bar drop!

Spend more time with your family.

Tencent optimal measurement

Tencent Youtest is a professional mobile cloud testing platform, providing product quality testing and problem solving services for r&d teams of applications, games and H5 hybrid applications. Not only does the online platform provide app automated testing, remote control and debugging of cloud real machine, private automated testing tool XTest and other quality testing tools, but also VIP customers are equipped with expert teams to provide customized comprehensive testing solutions.




I will share with you weekly articles from goose Factory

Don’t miss it