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 Same Origin Policy (SOP) is meant to prevent one website from requesting information on another website. In practice, data can be leaked from websites in other ways. A major one of these is timing of loading a resource.

An original vector was described by Chris Evans against Yahoo! Mail, where you can search the inbox of a website to see if results are returned or not based on the amount of time it takes. Later, this was coined as XSSearch with hard statistics on timing. Based on timing, a list of attack methods, such as frame counting, is becoming increasingly popular due to "browser misfeatures".

One of these methods that the author wants to bring to our attention is around browser caching. This can be used for timing attacks to understand if something was cached or not for the browser history. geographic information or general fingerprinting. Their variation is as follows:

1. Delete the cache for a specific resource.
2. Force the browser to render to a website as the user.
3. Check if the browser cached the resource.

They first check out Facebook for issues relating to this. According to them, URLs are signed, so it's not a simple cache or no cache problem. A good question to ask is " Does the image X get cached when the profile page is loaded?" By reviewing the cache, this could potentially be checked.

Another variant of this on Facebook is checking for user access to some resource, such as a private group. In this case, it requires that something cachable be loaded in some cases, such as a legitimate search, but not in an illegitimate search. When searching Facebook messages, an extra pop-up appears to confirm before any JavaScript loads, preventing this attack. Facebook has some pretty neat protections against these types of attacks!

How do we invalidate a cache entry? By making a POST request to the resource or issuing a Fetch API with a cache that returns an error from the server, such as a large HTTP referrer header. The final trick is quite simple: delete the cache, reload the page, and query the cache for the information. Crazy - the never-ending curse of caching.

They end the post with some caveats on exploitation and a note of a Wiki page with all known Cross-Site leak techniques. Great post!