Guest Blog by Hassan Mussana
Sites which want to implement CSP, send a special header value in the http responses with the name Content-Security-Policy. The Content-Security-Policy header value ismade up of one or more directives. Here a few common scenarios for setting directives:
Allow everything but only from the same origin
Only Allow Scripts from the same origin
Allow Google Analytics, Google AJAX CDN and Same Origin
script-src 'self' www.google-analytics.com ajax.googleapis.com;
Whether you want to check that CSP is working the way intended (e.g. blocking scripts or imgs from certain domains or loading themonly from certain domains etc.) or just want to try bypassing it, it’s prettystraight forward. In this CSP walkthrough, we are going to use a test site DVWA(Damn Vulnerable Web Application) which has been deployed locally for thiswalkthrough.
DVWA is a vulnerable web application that many security researchers use to sharpen their skills of exploiting web application vulnerabilities. Thereason for choosing DVWA for this walkthrough is not that it implemented theCSP (which in fact it doesn’t implement at all) but instead that we couldactually see an XSS attack thwarted by CSP. Of course, for that, we must havean XSS vulnerability in an application; and DVWA is just perfect for that.
So I did a little tweak to include CSP header in all http responses from DVWA by including:
Header set Content-Security-Policy"default-src 'self'; script-src 'self';"
to the file: /etc/apache2/apache2.conf (Ubuntuwith Apache)
Afterwards just restarted the apache server and there it is, in the response header.
In the video above, as you can see, I am easily able to locate the errors while the injection is being done and no dialog is appearing,instead we can only see Hello. As mentionedearlier, I have used:
Content-Security-Policy "default-src'self'; script-src 'self';"
So wherever our application tries to use a script which was either loaded in-line(in the case of stored XSS) or was not loaded from the server rather from theuser input (in case of Reflective), the CSP policy told Chrome not to executeit, hence the errors are seen in the logs:
Refused to execute inline script because it violates the following Content Security Policy directive: script-src 'self'
But oncechrome stops processing the CSP directives in http responses, we can observe the alert dialogs.
We can use Chrome’s developer tools to locate the issue too but it has its limitations.You’ll only be watching the live traffic as it is received by your browser.Tons of resources coming in and requests scroll going up and up, makes itdifficult to locate issues in real time. And if you want to observe a resourceagain, you will have to load the page again to see the request and response,while with BugReplay, all it takes is one recording which can be played,stopped and repeated whenever necessary. Moreover, you don’t have to create aPoC separately so it saves your precious bug hunting time too.
Hope you guys liked it!