A XSS

XSS (Cross-site Scripting) refers to cross-site scripting attacks. Attackers inject code into page A to steal information. In essence, data is executed as A program. XSS is very harmful, and generally XSS can do the following things:

  • Get the data of the page, including DOM, cookies, localStorage, etc
  • Hijack front-end logic
  • Send the request
  • .

1 XSS type

  • Reflective (non-persistent) : Direct injection via URL parameters
  • Stored (persistent) : Injected when stored in the database and read
  • DOM based: Malicious scripts executed modify the page script structure

2 Injection point of XSS

  • HTML node content or attributes
  • Javascript code
  • The rich text

3 XSS Defense

3.1 Browser Defense

Defense is related to X-xss-protection. The default value is 1, that is, XSS defense is enabled by default. It can defend against reflective XSS, but the function is limited. It is not recommended to rely only on this defense.

3.2 Defending against HTML node content

Code at risk:

<template>
    <p>{{username}}</p>
</template>

<script>
    username = "<script>alert('xss')</script>"
</script>

Copy the code

Compiled code:

<p>
    <script>alert('xss')</script>
</p>
Copy the code

The above example uses vUE syntax, but in fact, in a framework like Vue, {{username}} content is stringed, so it will not be executed by the browser. If you change to another template language such as Jade, there may be risks. The same below.

Defense code:

Defends HTML node content by escaping < for < and > for >.

<template> <p>{{username}}</p> </template> <script> escape = function(str){ return str.replace(/</g, '&lt; ').replace(/>/g, '&gt; ') } username = escape("<script>alert('xss')</script>") </script>Copy the code

3.3 Defending AGAINST HTML Attributes

<template>
    <img :src="image" />
</template>
<script>
    image = 'www.a.com/c.png" onload="alert(1)'
</script>
Copy the code

Compiled code:

<img src="www.a.com/c.png" onload="alert(1)" />
Copy the code

Defense code:

By escaping “for &quto; , ‘as the & # 39; To implement defense, generally do not escape Spaces, but this requires attributes must be quoted!

<template> <img :src="image" /> </template> <script> escape = function(str){ return str.replace(/"/g, '&quto; ').replace(/'/g, '&#39; ').replace(/ /g, '&#32; ') } image = escape('www.a.com/c.png" onload="alert(1)') </script>Copy the code

3.4 Defense against javaScript code

Assume that the page address is www.a.com? Id =1″. alert(1);”

Risk Code:

var id = getQuery('id')
Copy the code

Compiled code:

var id = "1"; alert(1);" "Copy the code

Defense code:

By serializing the data with JSON

escape = function(str){
    return JSON.stringify(str)
}
Copy the code

3.5 Defense against Rich Text

Risk Code:

<template> <p v-html="richTxt"></p> </template> <script> richTxt = '<a onmouseover=alert(document.cookie)> Click </a>' </script>Copy the code

In the above code, when the mouse moves over the “click”, the alert popover is triggered! This happens in VUE.

It is a complex project to defend against rich text, because rich text can contain HTML and script, which are difficult to predict and defend against. It is recommended to filter the allowed HTML tags and tag attributes by whitelist. The approximate implementation method is as follows:

  • Turn HTML code snippets into tree-structured data
  • Walk through every node in the tree, filter the type and attribute of the node, or do special processing
  • After the processing is complete, the tree structure is converted into HTML code

Of course, it can also be implemented through open source third-party libraries, such as JS-XSS.

3.6 CSP Content Security Policy

Content Security Policy (CSP) is an additional security layer used to detect and weaken certain types of attacks, including cross-site scripting (XSS) and data injection attacks.

CSP can configure a Content Security Policy for a page through HTTP headers (Content-security-Policy) or
elements to control which resources the browser can obtain for that page. For example, a page that can upload files and display images should allow images to come from anywhere, but limit the action attribute of the form to the specified endpoint. A properly designed content security policy should effectively protect pages from cross-site scripting attacks.

For details, go to MDN

4 About XSS defense in VUE

Vue already has some XSS defense in the framework. We try to use {{}} expressions for some foreign content (such as interface or URL parameters), because {{}} is stringed and the browser will not perform operations on the content.

Use v-HMTL instructions as little as possible, or XSS filter content first. Although HTML 5 specifies that the “script” tag inserted by innerHTML is not executed. But tags can have javascript listeners, such as onload, onError, onmouseover, and so on.

Two CSRF

Cross Site Request Forgery (CSRF) refers to cross-site Request Forgery. Different from XSS, XSS is an injection attack by the attacker directly to our website A, while CSRF is A forged request to our website A through Website B.

For example, if you log on to shopping site A and click on A malicious link B, B requests the ordering interface of site A, and the result is that your account on site A actually generates an order. The principle behind this is that website B forges the request of website A through forms and GET requests. At this time, the request will carry the cookies of website A. If the login state is saved in cookies, the forgery attack is implemented.

1 Hazards of CSRF

  • The login status of the user is stolen
  • Request to complete the business
  • .

2 Features of CSRF

  • Forged requests do not go through site A
  • The domain name of the forged request is not website A

3 CSRF Defense

Since it is easier to forge a GET request than a POST request (opening a URL or requesting a resource is a GET request), POST requests should be used as far as possible for interfaces involving business operations. In addition, CSRF can be defended based on the characteristics of CSRF.

3.1 Adding a Verification Code

One feature of CSRF is that the forged request does not go through website A, so we can add the verification means of website A, such as graphic verification code or SMS verification code, so that only the request that passes the verification is legitimate. However, this scheme has two limitations, one is to increase the development cost, the other is to reduce the user experience.

3.2 Cookies Set sameSite

As for the second feature of CSRF, the domain name of forged request is not website A, so cookies can be prevented from being used by websites with other domain names to achieve the purpose of defense. Specific methods are as follows:

Cookies Set the sameSite property to strict so that only requests from same-origin sites will have cookies. However, this scheme has browser compatibility issues.Copy the code

3.3 verify the referer

The second feature also causes the referer of forged requests not to be site A, so we can limit the source of untrusted requests. The specific approach is:

The backend can determine whether the request is from a trusted site based on the 'referer' of the HTTP request header. However, this scheme also has limitations, attackers can set requests not to carry referer, so this scheme is suitable for auxiliary purposes.Copy the code

3.4 Verifying the CSRF Token

This is one of the relatively mature schemes at present, and the specific approaches are as follows:

The server generates the token randomly and stores it in the server session and the client. When the client sends a request, it carries the token to the HTTP request header or parameter. The server receives the request and verifies whether the token in the request is consistent with that in the session.Copy the code

This scheme applies to projects that are not separated from the front end and projects that are separated from the front end. For projects that are not separated from the back end, the token can be written directly to the hidden fields of the form during template compilation, so that no additional operations are required to send the request. However, for the project with separated front and back ends, the token can be written into the cookies when logging in. When sending a request, JS reads the token in the cookies and sets it in the HTTP request header.

3.5 Changing the Login Mode Scheme

Because CSRF essentially forgery requests to carry information stored in cookies, the login status of session mechanism is adversely affected. If JWT (JSON Web Token) scheme is replaced, its Token information is generally set in the HTTP header, so CSRF attacks can be defended.

The pros and cons of the two logon schemes are not expanded here.

Three afterword.

That’s it for XSS and CSRF. If you want to learn more about front-end security besides XSS and CSRF, you can click on the following section of this article:

WEB front-end security – Cookie security, password security, click hijacking