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!

postMessage is a way to send data from site to site on the client side. In particular, it tends to be used with between iFrames, such as with the Youtube player. Since postMessage is normally considered trusted input, many XSS and information disclosure bugs have appeared from this in recent years. To find bugs in this, the author uses the tool PostMessage-tracker.

When using postMessage, it is important that the website checks the origin of the request. If this is not done, then the page can be iFramed and communicated with from another domain.

At this point, it is incredibly important to see how the data is actually be used. In this case, the event data could be used to change some window settings. When reviewing how this was done, it was loading a domain from Cloudfront and a subdomain that was controllable by the user. From there, it would grab the JavaScript to run it via an eval. Was this code secure?

The goal is to make the domain match a malicious server instead of the expected domain. By messing with the parsing of the region, a region of .my.website/malicious.php?_bad would work to add our domain in the front. This code is shown below:

  var region = window.settingsSync.region;
  var subdomain = region.split("_")[1]+'-'+region.split("_")[0]
  domain = 'https://'+subdomain+'.settingsSync.com'

At this point, an attacker could load arbitrary JavaScript within the context of this iFrame! By specifying their own attacker server to host the JavaScript, an alert box could be popped. But, this was JavaScript execution within the iFrame; can we go back to the original page?

The main page had its own postMessage handler for grabbing credentials! The iFrame, that we have JavaScript execution in, is an allowed origin in the communication to the main iFrame. Now, by running JavaScript in the context of the iFrame, we can make a request for credentials for the site. Damn, that's really cool!

The second bug started while looking at the OAuth confirm page page of a website. The URL for the request would dynamically create GET request based upon the client id in the confirmation page request. While messing with the response of the request, one of the fields was being inserted into the page without any sanitization. If the response of this request could be controlled, then the site would be vulnerable to XSS.

The query parameter domain allowed for the controlling of the URL. However, setting this to an arbitrary domain was not possible because of Content-Security-Policy (CSP) reasons. When making HTTP requests, they adhere to the connect-src CSP rule. Since the actual directive was not specified, it uses the default, which contained *.companyb.com and *.amazonaws.com. Since we can easily host a page on *.amazonaws.com, we can easily bypass this restriction to load in arbitrary content.

Again, the CSP caused problems. The only acceptable locations for scripts (defined by the script-srcself and *.companyb.com. From previous work on this website, the author tried finding an open redirect on the company website to allow us to load data from an arbitrary location, bypassing the CSP.

The open redirect had a restriction for the domain though: the string had to end with companyb.com in the URL. By providing a URL encoded newline (%0A), the domain validation could be bypassed. Then, when the browser parsed for the website, it would assume that the newline was the end of the domain! As a result, the open redirect could be used to achieve XSS through the filter bypass.

Both of these bugs are amazing finds when many steps along the way! Most applications are built with a secure inner wall. But, once you penetrate that inner wall, assumptions breaks down and security is not as good. By abusing several features of the website with tiny bugs, two major compromises eventually occurred.