Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Exploiting CSP in Webkit to Break Authentication & Authorization- 675

ThreatNixPosted 4 Years Ago
  • Content Security Policies (CSP) are rules to load resources in CSS, images and many other things. This can be defined in a response called the Content-Security-Policy or put into <meta> tags on the HTML. The CSP is implemented in most browsers but is quite complex to implement.
  • When a violation is made of the policy, this information can send the information. There are quite a few ways to send a report: the CSP report-uri in a CSP, a SecurityPolicyViolationEvent and two others.
  • There was one major issue with the original specification of the CSP though: the CSP recommended that the origin of the blocked URI was to be displayed. This is a problem because the blocked URL,from the redirect, could contain sensitive information cross origin.
  • Leaking the origin by using the blocked-uri has happened multiple times. In particular, Egor Homakov which uses a variation of this to fingerprint users across origins.
  • Safari does not adhere to the W3C specification. As a result, we can use the CSP to block a cross-origin redirection. When the CSP denies the request, the value being sent now may have a secret inside of it! Using the event handler, we have leaked a secret cross origin.
  • To exploit this with SSO, OAuth can be destroyed from this. When the website goes to the SSO location and gets redirected with a new OAuth code, we can leak the secret token from this! Damn, that's the worst cross-origin browser bug I have ever seen.
  • After reporting this to Safari in February of 2020, the response claimed that this was not a risk to WebKit users. It seems that the vulnerability was misunderstood by the WebKit team.
  • What are some fixes to this vulnerability on an OAuth implementation? Using SameSite cookies (I assume strict but they do not say), POST messages instead of GET, using postMessage and a few others. These are not true security fixes; but a workaround for a Safari bug that happens to not make implementations vulnerable.
  • To prevent this in the browser, include the original request in the error message and not he original target. They ended up finding a similar vulnerability in CORS as well!
  • We often take the security of browsers for granted and assume things work properly. What happens when the browser is bad? Companies have to include custom fixes and all hell breaks loose. From this, they got over 100K in bug bounties!