Content Security Policy (CSP), the core idea is very simple: a website sends a CSP header to tell the browser what it is authorized to do versus what needs to be disabled. It has been hailed as a godsend specifically designed to solve XSS attacks.
1. Preface
Content Security Policy (CSP) is an additional layer of security used to detect and cripple certain specific types of attacks, including cross-site scripting (XSS) and data injection attacks, among others. Whether it's data theft, contamination of website content or distribution of malware, these attacks are the mainstay.
The essence of CSP is a whitelisting system, where the developer explicitly tells the client which external resources can be loaded and executed, which is equivalent to providing a whitelist. Its implementation and execution are all done by the browser, the developer only needs to provide configuration.
CSP greatly enhances web security. Even if an attacker discovers a vulnerability, he or she will not be able to inject scripts unless he or she is also in control of a whitelisted, trusted host.
corresponds English -ity, -ism, -ization
Restricted access to resources
Ultra-authorized access to reporting resources
3. Mode of restriction
default-src limits global
Establishment of the type of restriction
The resource types are: connect-src, mainfest-src, img-src, font-src, media-src, style-src, frame-src, script-src...
4. Responding to threats
4.1 Cross-site scripting attacks
The primary goal of the CSP is to mitigate and report XSS attacks, which exploit a browser's trust in the content it receives from a server. Malicious scripts are able to run in the victim's browser because the browser trusts the source of its content, even though sometimes the script does not come from where it is supposed to.
CSP gives server administrators the ability to reduce or eliminate the vectors upon which XSS attacks are based by specifying valid domains - that is, valid sources of executable scripts recognized by browsers. A CSP-compliant browser will only execute script files obtained from whitelisted domains, ignoring all other scripts (including inline scripts and HTML event handling attributes).
As an ultimate form of protection, sites that always disallow script execution have the option of a total ban on script execution.
4.2 Packet Sniffing Attacks
In addition to restricting the domains in which content can be loaded, the server can specify which protocols are allowed; for example (in terms of idealized security), the server can specify that all content must be loaded over HTTPS. A complete secure data transfer policy not only enforces the use of HTTPS for data transfer, but also marks all cookies with the secure flag and provides automatic redirection of HTTP pages to the HTTPS version. A website can also use the Strict-Transport-Security HTTP header to ensure that browsers connecting to it only use encrypted channels.
utilization
CSP Classification:
（1）Content-Security-Policy
Once configured and enabled, external resources that do not comply with the CSP are prevented from being loaded.
（2）Content-Security-Policy-Report-Only
Indicates that the restriction option will not be enforced, but only the violation of the restriction will be logged. It must be used with the report-uri option.
CSP use:
(1) Use on HTTP Header (preferred)
"Content-Security-Policy:" policy
"Content-Security-Policy-Report-Only:" policy
(2) Use on HTML
<meta http-equiv="content-security-policy" content="be tactful">
<meta http-equiv="content-security-policy-report-only" content="be tactful">
The Meta tag and the HTTP header are only different in line format but serve the same purpose. If the HTTP header and the Meta definition exist at the same time, the definition in the HTTP is preferred.
Meta definitions are skipped if the user's browser has implemented a CSP policy for the current document. The META tag will also be skipped if it lacks a content attribute.
Example of CSP usage:
1. A webmaster wants all content to come from the same source on the site (excluding its subdomains).
Content-Security-Policy: default-src 'self'
2. A webmaster allows content from trusted domains and their subdomains (the domain does not have to be the same as the domain where the CSP is set up)
Content-Security-Policy: default-src 'self' *.
3. A webmaster allows users of a web application to include images from any source in their own content, but restricts audio or video to be obtained from a trusted resource provider, and all scripts must obtain trusted code from a specific host server.
Content-Security-Policy: default-src 'self'; img-src *; media-src ; script-src
By default, content is only allowed to be fetched from the source where the document is located, with the following exceptions.
- Images can be loaded from anywhere (note the "*" wildcard).
- Multimedia files are only allowed to be downloaded from the cap (a poem) loading (subdomains from these sites are not allowed).
- Runnable scripts are only allowed from the。
4. The administrator of an online banking site wants to make sure that all content on the site is captured over SSL to prevent attackers from eavesdropping on requests made by users.
Content-Security-Policy: default-src
This server only allows documents to be accessed over HTTPS and only from the domain name.
5. An online mailbox administrator wants to allow HTML to be included in emails, and again images are allowed to be loaded from anywhere, but not JavaScript or other potentially dangerous content (loaded from any location).
Content-Security-Policy: default-src 'self' *.; img-src *
Note that this example does not specify script-src, which in this CSP example is configured by the site through the default-src directive, which also means that script files are only allowed to be fetched from the origin server.
reporting-only model
To reduce deployment costs, CSP can be deployed in report-only mode. In this mode, the CSP policy is not mandatory, but any violations will be reported to a specified URI address. In addition, a report-only mode header can be used to test a revised policy that will be applied in the future without actually deploying it.
You can specify your policy with the Content-Security-Policy-Report-Only HTTP header, like this:
Content-Security-Policy-Report-Only: policy
If both the Content-Security-Policy-Report-Only header and the Content-Security-Policy appear in a response, both policies are valid. The policy specified in the Content-Security-Policy header is mandatory, while the policy in the Content-Security-Policy-Report-Only header generates only a report and is not mandatory.
CSP-enabled browsers will always send a violation report for every attempt to violate the policy you have established, if the policy contains a valid report-uri directive.
By default, violation reports are not sent. To enable sending violation reports, you need to specify the report-uri policy directive and provide at least one URI address to submit the report:
Content-Security-Policy: default-src 'self'; report-uri /
You then need to set up your server to be able to receive reports so that it can store and process them in a way that you think is appropriate.
Reference Article:
/zh-CN/docs/Web/HTTP/CSP#Example_2
/blog/2016/09/
/qq_37943295/article/details/79978761