CSP and SRI can prevent XSS attacks and packet sniffing attacks.

Content-security Policy (content-security Policy)

Introduction from MDN

Content-security-policy is an additional layer of Security that detects and defuses certain types of attacks, including cross-site scripting (XSS) and data injection attacks. Whether it’s data theft, contamination of website content or the distribution of malware, these attacks are the main means.

CSP is designed to be fully backwards-compatible (except that CSP2 has an explicit reference to inconsistencies in backwards compatibility; See section 1.1 here for more details. Browsers that do not support CSP can also work with servers that do, and vice versa: browsers that do not support CSP simply ignore it and run as usual, using the standard same-origin policy for web content by default. If the site does not provide a CSP header, the browser also uses the standard same-origin policy.

To make CSP available, you need to configure your web server to return the Content-security-policy HTTP header (sometimes you’ll see some reference to the X-Content-security-policy header, that’s an older version, you don’t have to specify it this way anymore).

HTTP Response Headers:

In addition, the
element can also be used to configure the policy, for example

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
Copy the code

strategy

"Content-Security-Policy": Policy stringCopy the code

Resource limits can be as fine-grained as IMG, font, style, frame, and so on.

default-src

Content-Security-Policy: default-src 'self'
Copy the code

A web site administrator wants all Content to come from the same source on the site (not including subdomains), content-security-policy /default-src

Media-src, img-src, and script-src

Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com
Copy the code

By default, content is only allowed to be retrieved from the source of the document, with the following exceptions:

  • Images can be loaded from anywhere (note the “*” wildcard).
  • Multimedia files are only allowed to be loaded from media1.com and media2.com (not from subdomains of these sites).
  • Runnable scripts are only allowed from userscripts.example.com.

‘unsafe-eval’

Allows you to use eval() and similar functions to create code from strings. There must be single quotation marks.

See CSP Directives for more details

Common Website Settings

  • zhihu

  • Twitter

Subresource Integrity

Subresource integrity (SRI) is a security feature that allows the browser to check whether the resources it has acquired (for example from a CDN) have been tampered with. It determines if the resource has been tampered with by verifying that the hash of the obtained file is the same as the one you supplied.

Many times we use CDN to share scripts and styles between multiple sites in order to improve site performance and save broadband. However, there are risks. If the attacker gains the control of the CDN, he can inject any content into the CDN file, thereby attacking the site that loads the CDN resources. So SRI is needed to ensure that files obtained by Web applications have not been injected by third parties or other forms of modification to reduce the risk of attack.

SRI principle

Subresource integrity is enabled by writing the contents of the file to the integrity value of the

The SRI Hash Generator is a tool for generating SRI hashes online.


<script src="https://example.com/example-framework.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
        crossorigin="anonymous"></script>
Copy the code

Content security policy and subresource integrity

You can configure your server according to the Content Security Policy (CSP) to make certain types of files SRI compliant. This is done by adding the require-sri-for directive to the CSP header:

Content-Security-Policy: require-sri-for script;
Copy the code

This directive states that all JavaScript must have an integrity property and be authenticated before it can be loaded.

Therefore, as long as the file changes, the browser will not execute, effectively avoiding script attacks.

Refer to the link

  • Developer.mozilla.org/zh-CN/docs/…
  • www.jianshu.com/p/217b11f5f…

About this article

  • Author: @ giscafer
  • Link: github.com/giscafer/fr…