Menu
 


During one of my recent security testing, I came across a very interesting scenario where some token was passing using GET requests. Of course I can sense some interesting things here. For the protection, this application was having almost all security headers that you will find in modern web application.


One of the headers that grab my attention was CSP.

https://www.xyz.com/upload/content/info/data/csp?parameter=tokens

For those who don’t know what is CSP can go through this good url.
Mozilla CSP Read
In simple word, CSP is used to prevent attacks like XSS, mix content security issues or things that lead to code injection into trusted resources.

Talking about in my target I noticed headers like.
Content-Security-Policy: default-src 'self' https://*.xyz.com https://www.xyz.com 'unsafe-inline';img-src https: data:;object-src 'none'; report-uri /upload/content/info/data/csp?parameter=tokens
Xyz.com we can see it was pulling the token in GET request and embedding to headers into  report-uri directive of their CSP. So if we inject anything there it will go into csp part.

There is a nice write up where I read about a similar case so I thought of trying something similar .so I used the semicolon and dash symbol  to inject into CSP.
Content-Security-Policy: default-src 'self' https://*.xyz.com https://www.xyz.com 'unsafe-inline';img-src https: data:;object-src 'none'; report-uri /upload/content/info/data/csp?parameter=tokens;-abc

Now that it's working let's create POC. Chrome by default ignores invalid directives and we have our injection point is getting embedded to end of the policy.so let's override the directives.
Well, many directives needed a hit and trial approach. Like
directive-name  = "script-src-elem"
directive-name  = "img-src"
directive-name  = "object-src"
and many checks here

you can use any directives that work for you.  I used one of  them script-src-elem.
The script-src-Elem directive applies to all script requests and script blocks. Attributes that execute script (inline event handlers) are controlled via script-src-attr. So as per our desired policy to attack would be.

Content-Security-Policy: script-src-elem 'none'; script-src-attr 'unsafe-inline'
<script>alert("Will be Blocked")</script>
<img src=X onerror="alert('Can run happily')">demo</a>

This directive overwrite existing script-src (which most directives behave)so you can bypass CSP easily.
The interesting thing about this directive is that it will overwrite existing script-src directives! So you can use it to bypass CSP provided you have policy injection
So the payload will be


so just by implementing the security doesn’t always help to make your product secure, of course, it adds a defense level but not 100% .hope you liked it.

Thanks for reading have a nice time ahead.


Post a Comment

Post a Comment

Feel Free To Ask Your Query we Love To Answer

 
Top