HTTP request processing isn’t atomic - any endpoint might be sending an application through invisible sub-states. This means that with race conditions, everything is multi-step. The single-packet attack solves network jitter, making it as though every attack is on a local system. This exposes vulnerabilities that were previously near-impossible to detect or exploit.

source: L

Despite the title, this isn’t so much a roundup of generic techniques but links to write ups of specific exploits. Good coverage.

As classic client-side vulnerabilities like XSS and CSRF get patched, CSP’d and SameSite’d into oblivion, niche attack techniques like DOM Clobbering are becoming ever more relevant. Michał Bentkowski recently used DOM Clobbering to exploit GMail, six years after I first introduced the technique in 2013. In this post, I’m going to quickly introduce DOM Clobbering, expand on my original research with some new techniques, and share two interactive labs so you can try the techniques out for yourself.

source: R

HTTP requests are traditionally viewed as isolated, standalone entities. In this paper, I’ll explore forgotten techniques for remote, unauthenticated attackers to smash through this isolation and splice their requests into others, through which I was able to play puppeteer with the web infrastructure of numerous commercial and military systems, rain exploits on their visitors, and harvest over $70k in bug bounties.

The protocol is extremely simple - HTTP requests are simply placed back to back, and the server parses headers to work out where each one ends and the next one starts. This is often confused with HTTP pipelining, which is a rarer subtype that’s not required for the attacks described in this paper. By itself, this is harmless. However, modern websites are composed of chains of systems, all talking over HTTP. This multi-tiered architecture takes HTTP requests from multiple different users and routes them over a single TCP/TLS connection:

Also: https://regilero.github.io/english/security/2019/10/17/security_apache_traffic_server_http_smuggling/

source: grugq

The first bug I want to talk about is how to close a HTML comment in a different way. If you read the HTML specification you’ll know that you can close a comment with --> or --!> but what about another way? This is a great question to start off fuzzing with. You just then need to generate some code that answers that question.

source: grugq

Following my presentation and whitepaper on Web Cache Poisoning last month, various companies have deployed defences in an attempt to mitigate cache poisoning attacks. In this post I’ll take a look at some common weaknesses that can be used to bypass them.

Ultimately, patching web cache poisoning on an ad-hoc basis can be tricky and the authors of web frameworks are the best placed people to resolve the most common types.

source: grugq

Web cache poisoning has long been an elusive vulnerability, a ‘theoretical’ threat used mostly to scare developers into obediently patching issues that nobody could actually exploit. In this paper 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.

Web cache poisoning is far from a theoretical vulnerability, and bloated applications and towering server stacks are conspiring to take it to the masses. We’ve seen that even well-known frameworks can hide dangerous omnipresent features, confirming it’s never safe to assume that someone else has read the source code just because it’s open-source and has millions of users. We’ve also seen how placing a cache in front of a website can take it from completely secure to critically vulnerable.

source: grugq

In the nine years since XSS Filter was first rolled out, the security component has been no stranger to controversy, as researchers successfully turned Microsoft’s frontline defense tool against itself.

Probably for the best.

source: grugq