XSS

Cross-site scripting, commonly referred to as XSS, is a kind of website application-style security vulnerability attack. It is a kind of code injection. It allows malicious users to inject code into a web page, affecting other users when they view it. Such attacks often involve HTML and client-side scripting languages.

XSS can be divided into three types: reflection, storage and DOM-based

How to attack

XSS attacks websites by modifying HTML nodes or executing JS code. For example, get some parameters from a URL

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

The above URL input might change the HTML to

, which would add an executable script to the page out of thin air. This type of attack is a reflex attack, or DOM-based attack. There are other scenarios, such as writing an article that contains attack code, and then it is possible that the user browsing the article will be attacked. This type of attack is storage attack, which can also be said to be DOM-based attack, and this attack is broader.

How to defense

The most common approach is to escape input and output, such as quotes, Angle brackets, and slashes

function escape(str) {
 str = str.replace(/&/g."&amp;");
 str = str.replace(/</g."&lt;");
 str = str.replace(/>/g."&gt;");
 str = str.replace(/"/g."&quto;");
 str = str.replace(/'/g."& # 39;");
 str = str.replace(/`/g."The & # 96;");
 str = str.replace(/\//g."&#x2F;");
 return str
}

Copy the code

By escaping, the attack code becomes

// -> < script> alert(1)< / script>
escape('<script>alert(1)</script>')
Copy the code

For displaying rich text, it is not possible to escape all characters as this would filter out the required format. In this case, whitelist filtering is usually adopted. You can also filter through the blacklist. However, because there are too many tags and tag attributes to be filtered, whitelist filtering is recommended.

var xss = require("xss");
var html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");
</script>');
// -> 
XSS Demo
< script> alert("xss"); < /script>
console.log(html);
Copy the code

CSP

Content Security Policies (CSP) are an additional layer of security designed to detect and weaken certain types of attacks, including cross-site scripting (XSS) and data injection attacks. Whether it is data theft, website content contamination or the distribution of malicious software, these attacks are the main means.

We can minimize XSS attacks with CSP. CSP is essentially a whitelist, specifying that the browser can only execute code from a particular source.

CSP can usually be enabled using content-security-policy in HTTP headers

  • Only site resources are allowed to be loaded

The Content ws-security - Policy: the default - SRC 'self'

  • Only HTTPS images can be loaded

Content-Security-Policy: img-src https://*

  • Allows loading of any source framework

Content-Security-Policy: child-src 'none'

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 method of hijacking a user to perform unintended actions on a currently logged Web application. [1] In contrast to cross-site directives (XSS), which leverage the user’s trust in a given site, CSRF utilizes the site’s trust in the user’s Web browser.

To put it simply, CSRF uses a user’s login state to initiate a malicious request.

How to attack

Assuming the site has an interface to submit user comments via a Get request, an attacker can add an image to the phishing site, and the address of the image is the comment interface

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

If the interface is posted, it’s a bit more cumbersome and requires a form to submit the interface

<form action="http://www.domain.com/xxx" id="CSRF" method="post">
 <input name="comment" value="attack" type="hidden">
</form>
Copy the code

How to defense

To prevent CSRF, follow the following rules:

  1. Get requests do not modify the data
  2. Do not allow third-party websites to access user cookies
  3. Prevents third party websites from requesting interfaces
  4. The request is accompanied by authentication information, such as a captcha or token

SameSite

You can set the SameSite property on cookies. This property sets cookies not to be sent along with cross-domain requests. This property can greatly reduce CSRF attacks, but it is not currently compatible with all browsers.

Verify the Referer

For the request to prevent CSRF, we can verify the Referer to determine whether the request is issued by a third party website.

Token

The server issues a random Token (the algorithm cannot be complicated), carries the Token each time it initiates a request, and the server verifies whether the Token is valid.