The following is from scotthelme.co.uk
with Content Security Policy (CSP) enabled(and a browser that supports it(http://caniuse.com/#feat=contentsecuritypolicy), you can tell the browser that it can only download content from the domains you explicitly allow http://www.html5rocks.com/en/tutorials/security/content-security-policy/ https://www.owasp.org/index.php/Content_Security_Policy I need to change our application code so we can increase security by disabling 'unsafe-inline' 'unsafe-eval' directives for css and js(if you have inline css or js, you will need to keep it too). more: http://www.html5rocks.com/en/tutorials/security/content-security-policy/#inline-code-considered-harmful
A browser that supports the Content-Security-Policy
header will only download content from domains explicitly allowed.
Content-Security-Policy-Report-Only
is similar, but only reports violations. Useful during implementation, tuning and testing efforts. Both headers may be sent together allowing for incremental changes to the policy.
Directives cannot be specified twice, as the second will be ignored.
# Wrong - No scripts would be loaded from google
Content-Security-Policy: script-src scotthelme.co.uk; script-src google.com
# Right
Content-Security-Policy: script-src scotthelme.co.uk google.com
There is no inheritance from the default source directive: would result in no scripts being loaded over https from scotthelme.co.uk.
# Wrong - Scripts would not be loaded over https from scotthelme.co.uk
Content-Security-Policy: default-src https:; script-src http://scotthelme.co.uk
# Right
Content-Security-Policy: default-src https:; script-src https://scotthelme.co.uk http://scotthelme.co.uk
self
: keyword for the current domain.default-src
: Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback),script-src
: Define which scripts the protected resource can execute,object-src
: Define from where the protected resource can load plugins,style-src
: Define which styles (CSS) the user applies to the protected resource,img-src
: Define from where the protected resource can load images,media-src
: Define from where the protected resource can load video and audio,frame-src
: Define from where the protected resource can embed frames,font-src
: Define from where the protected resource can load fonts,connect-src
: Define which URIs the protected resource can load using script interfaces,form-action
: Define which URIs can be used as the action of HTML form elements,sandbox
: Specifies an HTML sandbox policy that the user agent applies to the protected resource,script-nonce
: Define script execution by requiring the presence of the specified nonce on script elements,plugin-types
: Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded,reflected-xss
: Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header,report-uri
: Specifies a URI to which the user agent sends reports about policy violation
none
blocks the use of this type of resource.self
matches the current origin (but not subdomains).unsafe-inline
allows the use of inline JS and CSS.unsafe-eval
allows the use of mechanisms like eval().
These values specify additional locations assets can be loaded from.
data
: This allows data: URIs to be used, like base64 encoded images.mediastream
: This allows mediastream: URIs to be used.blob
: This allows blob: URIs to be used.filesystem
: This allows filesystem: URIs to be used.
If you want to safely inline script or style without using the 'unsafe-inline' directive you can use a hash value of the script or style to whitelist it. If you are considering using 'unsafe-inline' you should consider using a hash or nonce instead.
sha256-U53QO64URPPK0Fh7tsq0QACAno68LrPc5G6Avyy07xs=
This is the result of base64 encoding the binary hash of alert('Hello world!');. Any change in the script whatsoever will alter the resulting hash and the script will not be executed. This will also not whitelist externally hosted scripts, you still need to specify their origin. With this value placed in the script-src directive the browser would execute this inline script if it was placed in the page.
sha256-RB20JxKPtBo78ZjWkZ+GR4yOncuhVeK20jxJPz4x86c=
This is the result of base64 encoding the binary hash of color: #e6400c;. Any change in the style whatsoever will alter the resulting hash and the style will not be applied. This will also not whitelist externally hosted styles, you still need to specify their origin. With this value place in the style-src directive the browser would apply this inline style if was placed in the page.
If you want to safely inline script or style without using the unsafe-inline directive you can use a nonce value to whitelist the script or style. If you are considering using 'unsafe-inline' you should consider using a hash or nonce instead.
nonce-RANDOM_NONCE_VALUE
To use a nonce to whitelist a script on the page you would place the nonce value in the script tag like so: <script nonce="RANDOM_NONCE_VALUE">alert('Hi!');</script> The browser would now execute the script and the same method can be applied to a style tag. The nonce value should be a base64 encode of at least 128 bits of data from a cryptographically secure random number generator.
Note: Using a static nonce is not advised and is actually less secure than using the unsafe-inline directive. If the attacker utilises the nonce value, they can bypass all other restrictions in the CSP and execute any script they like. A nonce must be generated at random with each page load and inserted into the CSP and the DOM.
The established way of preventing clickjacking involves the use of the header X-Frame-Options (see: Clickjacking_Defense_Cheat_Sheet). However, CSP 2.0 has a new directive frame-ancestors
.
Content-Security-Policy: frame-ancestors: 'self' *.example.com
self
: keyword for the current domain.default-src
: Define loading policy for all resources type in case of a resource type dedicated directive is not defined (fallback),script-src
: Define which scripts the protected resource can execute,object-src
: Define from where the protected resource can load plugins,style-src
: Define which styles (CSS) the user applies to the protected resource,img-src
: Define from where the protected resource can load images,media-src
: Define from where the protected resource can load video and audio,frame-src
: Define from where the protected resource can embed frames,font-src
: Define from where the protected resource can load fonts,connect-src
: Define which URIs the protected resource can load using script interfaces,form-action
: Define which URIs can be used as the action of HTML form elements,sandbox
: Specifies an HTML sandbox policy that the user agent applies to the protected resource,script-nonce
: Define script execution by requiring the presence of the specified nonce on script elements,plugin-types
: Define the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded,reflected-xss
: Instructs a user agent to activate or deactivate any heuristics used to filter or block reflected cross-site scripting attacks, equivalent to the effects of the non-standard X-XSS-Protection header,report-uri
: Specifies a URI to which the user agent sends reports about policy violation
none
blocks the use of this type of resource.self
matches the current origin (but not subdomains).unsafe-inline
allows the use of inline JS and CSS.unsafe-eval
allows the use of mechanisms like eval().
These values specify additional locations assets can be loaded from.
data
: This allows data: URIs to be used, like base64 encoded images.mediastream
: This allows mediastream: URIs to be used.blob
: This allows blob: URIs to be used.filesystem
: This allows filesystem: URIs to be used.
If you want to safely inline script or style without using the 'unsafe-inline' directive you can use a hash value of the script or style to whitelist it. If you are considering using 'unsafe-inline' you should consider using a hash or nonce instead.
sha256-U53QO64URPPK0Fh7tsq0QACAno68LrPc5G6Avyy07xs=
This is the result of base64 encoding the binary hash of alert('Hello world!');. Any change in the script whatsoever will alter the resulting hash and the script will not be executed. This will also not whitelist externally hosted scripts, you still need to specify their origin. With this value placed in the script-src directive the browser would execute this inline script if it was placed in the page.
sha256-RB20JxKPtBo78ZjWkZ+GR4yOncuhVeK20jxJPz4x86c=
This is the result of base64 encoding the binary hash of color: #e6400c;. Any change in the style whatsoever will alter the resulting hash and the style will not be applied. This will also not whitelist externally hosted styles, you still need to specify their origin. With this value place in the style-src directive the browser would apply this inline style if was placed in the page.
If you want to safely inline script or style without using the unsafe-inline directive you can use a nonce value to whitelist the script or style. If you are considering using 'unsafe-inline' you should consider using a hash or nonce instead.
nonce-RANDOM_NONCE_VALUE
To use a nonce to whitelist a script on the page you would place the nonce value in the script tag like so: <script nonce="RANDOM_NONCE_VALUE">alert('Hi!');</script> The browser would now execute the script and the same method can be applied to a style tag. The nonce value should be a base64 encode of at least 128 bits of data from a cryptographically secure random number generator.
Note: Using a static nonce is not advised and is actually less secure than using the unsafe-inline directive. If the attacker utilises the nonce value, they can bypass all other restrictions in the CSP and execute any script they like. A nonce must be generated at random with each page load and inserted into the CSP and the DOM.
The established way of preventing clickjacking involves the use of the header X-Frame-Options (see: Clickjacking_Defense_Cheat_Sheet). However, CSP 2.0 has a new directive frame-ancestors.
Hi, thanks so much for your content. Could you please help me how could I use owasp-useful-headers.conf? Kind regards