Content Security Policy (CSP) allows the application to restrict the location of resources to an allow-list of approved locations, including where scripts can be loaded from and when the application may be framed. This can therefore mitigate reflected and stored cross-site scripting attacks as well as issues such as Clickjacking.
ClickJacking may also be prevented using the X-Frame-Options security, however this is not fully implemented in some browsers, for example in Chrome the only available options are DENY and SAMEORIGIN.
Content Security Policy is enabled by supplying a Content-Security-Policy HTTP response header. The CSP header is made up of two parts, a list of directives and a list of approved locations.
It is recommended that at a minimum the following directives are supplied: script-src, object-src, style-src, and frame-ancestors. It is also recommended that no directives marked as unsafe are included, for example ‘unsafe-inline’ and ‘unsafe-eval’.
The following are examples of available directives:
| default-src | A default allow-list for where more specific directives have not been supplied. |
| script-src | Specifies where JavaScript can be loaded from. |
| img-src | Specifies where images can be loaded from. |
| style-src | Specifies where CSS can be loaded from. |
| connect-src | Specifies where features such as XMLHttpRequest may connect to. |
| font-src | Specifies where fonts may be loaded from. |
| object-src | Specifies where object, embed, and applet elements may be loaded from. |
| media-src | Specifies where audio, video and track elements may be loaded from. |
| frame-src | Frame-src is for where frames can be loaded from, which was deprecated in CSP Level 2 and then undeprecated in CSP Level 3. |
| frame-ancestors | Specifies where this page may be framed from. Setting frame-ancestors to ‘none’ is the equivalent of setting the X-Frame-Options header to DENY. |
The following are examples of source locations that can be given to directives:
| * | A wildcard to allow any URL except data: and filesystem: schemes. |
| ‘none’ | Disables this resource type |
| ‘self’ | Allows resources from the same-origin |
| data: | Allows the loading of resources via the data scheme, such as base64 encoded images |
| domain.example.com | Allows loading resources from the specified domain |
| *.example.com | Allows loading resources from any subdomain of the specified domain |
| https://example.com | Allow loading resources from the specified domain, if supplied over HTTPS |
| https: | Allow loading resources from any domain, if supplied over HTTPS |
| ‘unsafe-inline’ | With script-src, allows the use of inline JavaScript; considered unsafe as it may allow for Cross-site Scripting attacks. With style-src, allows the use of inline CSS; considered unsafe as it may allow for virtual defacement. |
| ‘unsafe-eval’ | Allows the use of JavaScript eval(), a function, which may allow for DOM-XSS attacks. The eval() function is described by MDN as “an enormous security risk”. |
| ‘sha256-‘ | Allow scripts to execute if they match the supplied hash. sha256-, sha384-, or sha512- may be used. |
| ‘nonce-‘ | Allow scripts to be used if they include a nonce= attribute which matches the supplied none entry in the header. These numbers should not be used for more than one script, instead additional nonce- entries should be supplied. |
The source list can be used, with the directives to build a policy. For example:
Content-Security-Policy: default-src: 'none'; script-src: js.example.com; img-src: static.example.com; font-src: static.example.com;References
Becoming a Penetration Tester
Breaking into Penetration Testing can be a daunting career move; so in this article we talked about ways you can make your first move towards a career in this industry. To be clear, this isn’t a definitive guide to the industry – it’s just our opinion on what has worked [...]| Play | Cover | Release Label |
Track Title Track Authors |
|---|