Safety precautions

In general, security is a complex area, and it is impossible to learn everything in this article. We will learn about common security issues and how to prevent them. Nowadays, security issues are becoming more and more important and have gradually become a necessary skill for front-end development.

XSS

What is an XSS attack? How do I defend against XSS attacks? What is CSP?

Simply put, XSS means that an attacker tries to inject executable code into a web page by any means possible. XSS can be divided into several types, but in general I think there are two types: persistent and non-persistent.

Persistent is the attack code is written into the database by the server, this attack is very harmful, because if the site traffic is large, it will lead to a large number of normal access to the page users are attacked. For example, the comments feature is protected against persistent XSS attacks because I can type the following in the comments

If this situation is not defended at the front and back ends, the comment will be stored in the database, and everyone who opens the page will be attacked.

Non-persistent compared to the former is much less harmful, generally through the modification of URL parameters to join the attack code, induce users to visit the link so as to attack. For example, if the page needs to retrieve certain parameters from the URL as content, it will cause the attack code to be executed without filtering

<! -- http://www.domain.com?name=<script>alert(1)</script> --> <div>{{name}}</div>Copy the code

But for this type of attack, if the user is using a browser like Chrome, the browser can automatically defend the user against the attack. But that doesn’t stop us from defending against this type of attack, because I can’t be sure that everyone is using this type of browser.

Escape character

First, you should never trust user input. The most common way is to escape input and output, escaping quotes, Angle brackets, and slashes

function escape(str) {
  str = str.replace(/&/g, '& ')
  str = str.replace(/</g, '< ')
  str = str.replace(/>/g, '> ')
  str = str.replace(/"/g, '&quto; ') str = str.replace(/'/g, '' ') str = str.replace(/`/g, '` ') str = str.replace(/\//g, '/ ') return str }Copy the code

The attack code ==== can be escaped into

// -> &lt; script&gt; alert(1)&lt; &#x2F; script>
escape('<script>alert(1)</script>')
Copy the code

However, for displaying rich text, it is obviously not possible to escape all characters through the above method, because it would filter out the desired format. In this case, you can use the whitelist filtering method or the blacklist filtering method. However, considering that there are too many tags and tag attributes to be filtered, the whitelist filtering method is recommended.

const xss = require('xss')
let html = xss('
XSS Demo
') // -> <h1>XSS Demo</h1>&lt; script&gt; alert("xss"); &lt; /script&gt; console.log(html)Copy the code

The above example uses ==js-xss==, and you can see that the ==h1== tag is preserved and the ==script== tag is filtered in the output.

CSP

CSP is essentially a whitelist, where the developer tells the browser exactly what external resources can be loaded and executed. We just need to configure the rules, how to intercept is up to the browser itself. We can minimize XSS attacks in this way.

CSP can usually be turned on in two ways:

  1. Set == content-security-policy == in the HTTP Header
  2. Set ==meta== tag by ====

Here’s an example of setting the HTTP Header

  • Only site resources can be loaded
The Content ws-security - Policy: the default - SRC 'self'Copy the code
  • Only HTTPS images can be loaded
Content-Security-Policy: img-src https://*
Copy the code
  • Allows loading of frameworks from any source
Content-Security-Policy: child-src 'none'
Copy the code

Of course, there are many more properties that you can set, and you can learn about them by looking at the documentation, so I won’t go into the rest of them here.

In this way, as long as the developer configures the correct rules, even if the site is vulnerable, the attacker cannot execute its attack code, and the CSP compatibility is good.

CSRF

What is a CSRF attack? How do I defend against CSRF attacks?

CSRF is called cross-site Request forgery in Chinese. The idea is that the attacker constructs a back-end request address and induces the user to click or automatically initiate the request through some way. If the user is logged in, the back end assumes that the user is doing the operation and does the corresponding logic.

For example, if a website has an interface for submitting user comments via ==GET== requests, an attacker could add an image to a phishing site whose address is the comment interface

<img src="http://www.domain.com/xxx?comment='attack'"/>
Copy the code

Do you think that if you use ==POST== to submit a request, you will not have this problem? It’s not, and it’s not 100% secure. An attacker can also lure a user to a page and submit a request via a form.

How to defense

The defense against CSRF attacks can follow the following rules:

  1. The Get request does not modify the data
  2. Do not allow third party websites to access user cookies
  3. Block third party websites from requesting interfaces
  4. The request comes with authentication information, such as a verification code or Token

SameSite

You can set the ==SameSite== attribute on the Cookie. This attribute indicates that cookies are not sent with cross-domain requests and can significantly reduce CSRF attacks, but this attribute is not currently compatible with all browsers.

Verify the Referer

For requests that need to be defended against CSRF, we can verify the Referer to determine whether the request was initiated by a third party site.

Token

The server sends a random Token and carries it with it each time it initiates a request. The server verifies whether the Token is valid.

Click on the hijacked

What is clickjacking? How to prevent clickjacking?

Clickjacking is a visual trick attack. Attackers embed the site they want to attack into their own web pages through nested iframes, and set the iframe to be transparent, with a button in the page to induce users to click.

X-FRAME-OPTIONS

== x-frame-options == is an HTTP response header that is well supported in modern browsers. This HTTP response header is designed to defend against clickjacking attacks nested with ==iframe==.

The response header has three optional values, which are

  • ==DENY== : indicates that the page cannot be displayed using the iframe
  • ==SAMEORIGIN== : indicates that pages can be displayed using iframe in the same domain name
  • == allow-from == : indicates that the page can be displayed in the iframe of the specified source

JS defense

For some ancient browsers, and can not support the above way, then we have to use JS way to defend against click hijacking.

<head>
  <style id="click-jack"> html { display: none ! important; } </style> </head> <body> <script>if (self == top) {
      var style = document.getElementById('click-jack')
      document.body.removeChild(style)
    } else {
      top.location = self.location
    }
  </script>
</body>
Copy the code

What the above code does is when the page is loaded with ==iframe==, the attacker’s page simply doesn’t show everything.

Man-in-the-middle attack

What is a man-in-the-middle attack? How to prevent man-in-the-middle attacks

In a man-in-the-middle attack, the attacker establishes a connection with both the server and the client and makes the other side think that the connection is secure, but in fact the entire communication process is controlled by the attacker. The attacker can not only obtain the communication information of the two parties, but also modify the communication information.

Using public Wi-Fi is generally not recommended because of the possibility of a man-in-the-middle attack. If you involve sensitive information in the process of communication, you are completely exposed to the attacker.

Of course, the defense against man-in-the-middle attack is actually not difficult, just need to add a secure channel to transmit information. HTTPS can be used as a defense against man-in-the-middle attacks, but that’s not to say that you’re safe with HTTPS, because if you don’t completely disable HTTP access, there are ways for an attacker to degrade HTTPS to HTTP and achieve a man-in-the-middle attack.

summary

In this article, we learned some common front end security aspects and how to defend against these attacks. But the area of security is quite large, and this content is just a drop in the ocean. If you are interested in security, you can read the contents of this warehouse to learn and practice this knowledge.