2

I'm assessing the security level of a webapp and one of the test cases is the CSP header. I always use the Google CSP evaluator to assess the header. Let's consider the following CSP header:

Content-Security-Policy:
img-src 'self' https://example.com data: www.google-analytics.com;  
object-src 'self' https://example.com data:; 
script-src 'self' https://example.com www.google-analytics.com;

The evaluator states that there are two high severity findings; one for allowing the data attribute for an object element; other one for missing the base-uri directive. So I thought: "Hey, that's great, then maybe we can still exploit XSS by bypassing the CSP."

However, in my local webserver set-up with the CSP header above, the CSP policy still triggers a violation when injecting object elements with a data attribute or a base element. I'm rendering a page which echoes the user input from a query string right into the page unescaped.

I've read some articles about people succeeding in bypassing CSP with object elements and base-uri's like these:

<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
<base href="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg==" />

Result:

Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).

The CSP policy blocks these payloads as it states that inline scripts are not allowed. Even with a barebone CSP like default-src 'self' the violation still triggers.

  1. Has something changed over time or am I just doing it wrong?
  2. Are data attributes URI's etc. always seen as inline scripts?
  3. How 'high' are these findings then? Only setting 'unsafe-inline' will make the bypasses work, but that completely makes the bypass useless, because then you can inject script tags whatsoever.

0

You must log in to answer this question.

Browse other questions tagged .