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 ReadIn 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>
<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