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!

AppCache in Chrome was used for offline browsers and speed. AppCache has been announced that is permanently removed in Chrome 85. Some sites will still have it until Chrome 93, which is the last dying breath of AppCache. Because of this deprecation (and previous security issues), the author took the time to audit the security of AppCache.

This functionality works by having a manifest file that lists URLs that the browser should cache for the application. With the file, there are a few sections: Cache, Network and Fallback. The Cache is for files being downloaded, the network is for allowlisted resources that need a connection to the server and the fallback is what to do is the resource is inaccessible. For more on this, visit Mozilla.

The author was particularly concerned with the cross-origin issues, in order to find a larger impact. This gives some more context to how the author was thinking about attacking the application.

AppCache does not allow for redirects, according to the specification. However, this creates an oracle: if a redirect occurs, then the user is unauthenticated; if a redirect does not occur, they are authenticated. This could be used on Facebook, for instance, to see if a user was logged in or not. However, this was limited to did a redirect occur?

By using the Network tag, they were able to find another part to the Oracle. The network field is an allowlist of URLs that are allowed to make a request from, even across domains. By using this allowlist, it was possible to deduce a stronger primitive: which user was logged into Facebook!

If the /me endpoint on Facebook redirected to /victim, then the proper username had been found. However, if this resulted in an error message, this was NOT in the allowlisted set of domains. Because the redirect was rejected, this helps us know if the user is logged in AND which user they are.

To make this attack even stronger, there are glob (wildcard - *) characters that can be used in the manifest feature. Damn, this means that a character by character brute force can happen, which is a big cross-site oracle to have. This can also be used based upon a prefix for the URL, which acts the same way for the attack.

To make this even more efficient, binary search can be used by having a specific amount of entries in the network tab in specific orientation. For instance, have the wildcard glob start out with [a-m] range with a*, b*...m*. If this works, cut the range in half. If it does not work, then use [n-z]. Continue this process until the character has been found.

Practically, this could be used for URLs and the parameters of the URLs. While looking at the Chrome issue tracker, they noticed that CSRF tokens were sometimes in the URL parameters. Using the attack described above, the CSRF tokens were able to be stolen!

The CSRF generation endpoint would trigger each time, invalidating the old token though. So, how can we get around this? By making the request with the force-cache flag for cache, the request would be made locally from the browser, instead of the endpoint. No, it's all a matter of time to get the CSRF token!

The first fix was to remove support for the glob functionality altogether. I could not find the code for the second issue so I'm unsure how this was fixed; potentially just removed the prefix functionality.