General front-end security issues

Security issues we often encounter in front-end applications:

Cross-site scripting (XSS)
Cross-site Request Forgery (CSRF)
Clickjacking attack
Middleman hijacking

What is an XSS attack

XSS cross-site scripting attacks are attacks in which an attacker writes malicious code to a page to obtain sensitive user information such as login information. Generally, according to the different sources of attack, it is divided into three types:

Stored XSS attack: the attacker uses a vulnerability to submit a piece of malicious code to the server database, and then the user requests a page containing the malicious code. When the user browses this page, the malicious code script exposes some sensitive information of the user.
Reflective XSS attacks: Usually the attacker places malicious code on the parameters of the redirect URL. When the site takes the parameters and splices them into HTML, it executes them on the browser.
DOM XSS attack: Compared with the previous two DOM attacks, which do not involve servers, attackers inject malicious scripts into pages through various means, such as network hijacking, which inserts malicious codes in the process of page transmission. This type of hijacking can be realized in many ways, such as WIFI router hijacking, local malware hijacking and so on. The data on a Web page is modified in transit or when the user is using the page.

How do I prevent XSS attacks

An XSS attack has two main elements: the attacker submits injected malicious code, and the browser executes malicious code.

The most common way to never trust user input is to escape user input and output and filter user input to prevent attackers from submitting malicious code.
Take full advantage of the CSP (Content Security Policy), which is essentially a whitelist that explicitly tells the browser which external resources can be loaded and executed, we just need to configure the rules, and the browser will do the blocking itself.

CSP can be enabled in two ways:

Set content-security-policy in the HTTP Header

 Content-Security-Policy: default-src 'self' // Only local resources are allowed to be loaded
 Content-Security-Policy: img-src https:// Only HTTPS images can be loaded
 Content-Security-Policy: child-src 'none' // Allow loading of any source frame
Copy the code

How to set the meta tag

<meta http-equiv="Content-Security-Policy" content="script-src 'self'; object-src 'none'; style-src cdn.example.org third-party.org; child-src https:">
Copy the code

You can view the content security policy document when configuring a policy

Setting Cookei HttpOnly When a Web application sets the Cookei attribute to HttpOnly, it can prevent the Cookei from being obtained by malicious scripts.

What a CSRF

CSRF is called cross-site request forgery. The principle is that an attacker constructs a back-end request address and induces the user to click or initiate a request through a phishing website. If the user is logged in, the back-end considers that the user is operating and responds logically.


<! DOCTYPEhtml>
<html>
<body>
  <h1>Hacker's Site: CSRF attack demo</h1>
  <form id='hacker-form' action="https://time.geekbang.org/sendcoin" method=POST>
    <input type="hidden" name="user" value="hacker" />
    <input type="hidden" name="number" value="100" />
  </form>
  <script> document.getElementById('hacker-form').submit(); </script>
</body>
</html>
Copy the code

In this code, the attacker builds a hidden form on his own page. When the user clicks on the site, the form is automatically submitted, with the corresponding Cookei, and the cross-site POST data is submitted.

How to prevent CSRF

As we know above, attackers usually launch CSRF attacks by using user login state, and Cookei is a key data for maintaining login state before browsers and servers.

If a third-party site initiates the request, the browser forbids sending certain critical Cookei data to the server, in the HTTP response header, throughset-cookeiThe cookei field can be set with the SameSite option to prohibit third-party cookei.
The server can verify the source of the request through the HTTP request headerRefererandOriginProperty to determine the source address, circumvent requests from third party websites.
Add CSRF-token When sending a request, a Token is added as a parameter, and the server verifies whether the Token is valid.

Click on the hijacked

Principle: Click hijacking is a kind of visual deception attack method, the attacker will attack the website through the way of iframe nesting embedded in their own web pages, and set the IFrame transparent, in the page to reveal a button to induce users to click.

Defense methods:

** X-frame-options: ** THE HTTP response header property is a good defense against clickjacking and has three values:DENY(Always disallow this page from being displayed in frame.) .SAMEORIGIN(Allows the page to be displayed in a frame of the same origin as the parent document.) .ALLOW-FROM domain(Allows this page to be displayed in a frame from the parent document of a given domain.)

Middleman hijacking

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

Defense mode:

Using HTTPS, the SSL layer is an addition to the HTTP protocol. SSL layer relies on certificates to verify the identity of the server and encrypt the communication between the browser and the server. In this way, even if an attacker intercepts a user’s request, it cannot decrypt the information, let alone tamper with it.

General front-end security issues