CSP–How It Works
CSP is transferred to the browser through the content security policy HTTP header having one or more than one directives that whitelist the domains from which browser is granted permission to load the resources. If you take CSP 1.0, it has the directives mentioned below:
With the default-src, you are in a position to set the default source list for the directives that are remaining. If the directive is not in the CSP header in an exclusive manner, it falls back to the level of value usage mentioned in the default-src list.
Capturing The CSP Violations
If there is any violation related to the CSP that finally has an impact on performance, it is logged to the browser console. It may be good if the site is in a state of development; it is not practical if you deploy CSP for production. You can make use of report-uri for logging all the CSP violations.
If you are planning to implement CSP, you can use CSP-report-only HTTP header rather than the CSP. It works in a similar manner like the CSP header but it primarily reports on the violations or disruption of rules without enforcement of the policy and this it does by blocking the restricted resources. You can make use of both headers at the same time. You can enforce one policy and at the same time monitor the impact of changes on the other. All this is implemented to ensure the best web practices.
Protection of Inline Styles And Scripts
The nonce is a random string generated on the server and this includes the CSP header. The inline script tag is also included.
Protection of Inline Styles and scripts making use of Hash
When it comes to the content security policy data, you can first compute the hash of style or simply script block on server and theme and include this in style-src or script-src respectively. After that, the browser computes a hash of style/script block before rendering the page. If the hash that is computed by browser matches the one on the server, you can allow style/script block for execution.
Malicious attack and CSP design
The malicious attack occurs in the form of data theft to the site defacement or malware distribution. CSP is designed to be totally backward compatible except in the case of CSP version 2 where you can find explicitly mentioned inconsistencies in the area of backward compatibility. Browsers that do not support it work still with the servers implementing it and vice versa. Browsers that do not support the CSP just ignore it.
The main goal of CSP is mitigation as well as the report of XSS attacks. With the XSS attack, the trust of the browser is gone as far as the incoming content from the server is concerned. Malicious script is executed by the browser of the victim because the browser trusts the content source. With CSP and the content security policy data, the server administrators can diminish or finish vectors responsible for the occurrence of XSS by the specification of the domains considered by the browser as a valid source of executable scripts. After this, the CSP compatible browser will execute scripts that are loaded in the source files after receiving from the allowed domain lists. It ignores the other scripts including inline scripts as well as event handling HTML attributes. If you want ultimate protection, sites that do not permit the execution of scripts can opt for disallowing script execution globally.
Configuration of CSP involves the addition of CSP [content security policy] HTTP header with the web page. For example, a page uploading and displaying images permits images from anywhere. You need the properly designed content security policy and this helps protection of the page against the cross-site scripting attack.
Preventing web application vulnerabilities by CSP
CSP [content security policy] has the potential to prevent cross-site scripting vulnerabilities, security issues related to the mixed content, clickjacking, protocol downgrading and any type of code injection that is the result of the infusion of non-reliable content into a reliable source. You can implement a content security policy in your web applications by different methods.
A—Whistling of domains
The whitelist permits inline scripts. Domain whistling looks like a good notion but you have to be careful when you use it. The reason is attackers get unauthorized access and disrupt the best web practices. They will have unauthorized access to the web application’s code. You can do this on trusted domains generally controlled by the owner of the site.
B-Making use of Nonce
The Nonce has to be a random string that is made with cryptographically safe function to ensure it is unpredictable. In the content security policy, the notion behind nonce is that the attacker cannot know and you can refresh on each new page load. The developer will have to add once to the resource he is interested in loading. You can add the nonce to the script call because you cannot execute all script blocks without nonce without CSP setting as mentioned. If the attacker injects the script block into a page, he will not be able to know the nonce as it is generated at random on the call. Therefore the injection has the least impact on the user. It is better to revise information security policy contents if you want to gain not only well but a thorough knowledge of it.
You can also configure the content security policy to the load sources if they match the defined hashes. This is the reason you cannot execute the resources that are tampered with. For setting such a hash, you can use the CSP header as mentioned below:
Content-Security-Policy: script-src ‘self’ ‘sha256-78iKLlw3hSqddlf6qm/PGs1MvBzpvIEWioaoNxXIZwk=
The main benefit of such hash is that it is to be generated once for the good production and it provides safety against tampering with the script. The simple domain whitelist will not guarantee that.
Activation of content security policy
You can activate the content security policy by making use of the HTTP response headers or the HTML Meta elements. If HTTP headers are similar for each page, then you have the option to configure them at the level of the webserver. If the HTTP header is different for each page or on each reload or when you use the nonce or hask, then you can generate a web application level.
Example of CSP rule
console.log (“code works”}
You can send the above rule by making use of the HTTP response header or Meta element. The nonce is random and there is no need to reuse it. External scripts are induced in case nonce is in the script tag they are called with. If it does not match or nonce is not there, the script will not be executed or loaded. You can get the best services for Websites from Best Web Development Company in Nagpur.