Practical Web Cache Poisoning: Redefining 'Unexploitable'

The presentation discusses the dangers of header-based input, hidden functionality in frameworks, and cache poisoning in web applications.

• Header-based input is inherently dangerous and can be exploited by attackers to take control of web applications.
• Frameworks can hide lethal functionality that can be exploited by attackers.
• Cache poisoning is a real threat to web applications and can be used to steal sensitive information.
• An anecdote is given about how the speaker was able to exploit a security company's website using cache poisoning.
• The speaker provides tips on how to prevent cache poisoning, such as avoiding header-based input and auditing applications for unkeyed inputs.
• The speaker also suggests turning off caching if it is not necessary to prevent cache poisoning.

The speaker shares a story about how they were able to exploit a security company's website using cache poisoning. They registered themselves on a website and put some malicious HTML on it, which was then served up on the security company's website. Using this, the speaker was able to take full control over any page on any website hosted on the security company's platform. The speaker reported the issue to the security company, who resolved it by permanently banning the speaker's IP address.

Modern web applications are composed from a crude patchwork of caches and content delivery networks. In this session I'll show you how to compromise websites by using esoteric web features to turn their caches into exploit delivery systems, targeting everyone that makes the mistake of visiting their homepage. I'll illustrate and develop this technique with vulnerabilities that handed me control over numerous well known websites and frameworks, progressing from simple single-request attacks to intricate exploit chains that hijack JavaScript, pivot across cache layers, subvert social media and misdirect cloud services in pursuit of the perfect exploit. Unlike previous cache poisoning techniques, this approach doesn't rely on other vulnerabilities like response splitting, or cache-server quirks that are easily patched away. Instead, it exploits core principles of caching, and as such affects caching solutions indiscriminately. The repercussions also extend beyond websites - I'll show how using this approach, I was able to compromise Mozilla infrastructure and partially hijack a notorious Firefox feature, letting me conduct tens of millions of Firefox browsers as my personal low-fat botnet. In addition to sharing a thorough detection methodology, I'll also release and open source the Burp Suite Community extension that fueled this research. You'll leave with an altered perspective on web exploitation, and an appreciation that the simple act of placing a cache in front of a website can take it from completely secure to critically vulnerable.