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!

The author was hunting for a CSRF vulnerability when they noticed some odd functionality: a random subdomain was capable of performing authorized actions on the main API of the website. This was possible because of a cookie named sid with SameSite=None and Secure. This request required a valid CSRF token though.

From testing, the CORS policy was verbose, allowing all requests from subdomains of the main domain. What does this mean? XSS on any sub-domain from the website would lead to access to the sensitive API. They went after some out of scope subdomains on the site, which is a weird thing to do.

While on another site, they noticed a postMessage call without an origin check; this is a pretty obvious bad code sink. The functionality was calling arbitrary functions from app window, potentially leading to XSS. However, they couldn't find an easy eval() or something else simple.

This turned into a ROP-like challenge, where the user can call arbitrary functions within the application. The function APP.util.setCookie() allowed them to set arbitrary cookies on the various domains. Additionally, they found a powerful JSONP endpoint. The purpose was sending a call to a JSONP endpoint to lead an external script with the user choosing the domain.

This JSONP code that could load arbitrary JavaScript is real bad! Since the data could be reflected, by making a postMessage call to this, it would load inline JavaScript. How do we get a one-click interaction though? I don't believe that the postMessage call is accessible from other windows.

We need a reference to the page in order to send data via postMessage. But, the website had X-Frame-Options: SAMEORIGIN options, which prevented framing. As an attacker, this can still be opened in a pop-up window to get a reference, which is news to me!

Using the issues above, we can do the following:

1. Get user to visit our page.
2. Open a pop-up window that creates a reference to the page with the vulnerable functionality.
3. Use the postMessage call to get XSS via the JSONP endpoint.
4. Our attack payload is to ask for a CSRF token then make various API calls to modify and retrieve data.

Overall, a great bug chain leading to a horrible CSRF. To me, the poorly misconfigured CORS and lack of origin check on the postMessage were defense-in-depth issues that led to the exploitation of this; this is why these small things matter.