That Evolution mail caching behaviour is really sketchy. I wonder if it could be used for an exploit in the right scenario. If nothing else, it’s a good way to make an email that looks completely different depending on which client it’s opened in.
I love this, thanks for sharing. When I failed to get a measurable time difference myself I was worried I might just be doing something wrong and it'd get flagged the moment I published my research, so it's great to get confirmation from other people.
With the single-packet attack, you look at the order that the responses arrive in, instead of the time they take to arrive. Since the responses are on a single TLS stream, they always arrive at the client in the order that the server issued them in. Hope that makes sense!
tldr: curl's --data-binary argument normally specifies arbitrary data to send to the server. However, if the argument starts with an @, curl instead treats it as a filename, and sends the file contents to the server.
This technique is likely to work on anything with 'copy as curl' functionality, and may also work on some websites with SSRF where you control a request body or header name.
I wrote this up but full credit goes to Paul Mutton for reporting it to our bug bounty program, and agreeing to let us publish the technique.
This might not be relevant to you, but a lot of runners/cyclists exercise at 'tempo' - an intensity higher than necessary which mostly generates more fatigue without much benefit.
I think HTTP/2 is fine when it's used end to end. So if you've got a single webserver setup, or a reverse proxy that speaks HTTP/2 to the back-end, it's great.
However, if the only way you can use HTTP/2 is by having the front-end downgrade it to HTTP/1, I would recommend disabling it.
Good question! So, my understanding is that the majority of servers that are vulnerable to regular cross-user HTTP Request Smuggling (IE, reuse connections to the back-end server) are exposed to this terrifying response queue poisoning attack. This applies to all desync types CL.TE, TE.CL, H2.CL, etc. The reason I discovered this in the H2.X case, is because it's particularly easy to trigger response queue poisoning by accident in this scenario.
That said, I haven't actually tested this on very many live servers, for obvious reasons!
Yes that's right. If the back-end received a request that didn't contain X-Forwarded-SSL or suchlike, and had a host-header that ended in .netflix.com, it would redirect you to the host-header.
I wouldn't exactly class this as a vulnerability - more of a useful gadget. The front-end would refuse to forward such a request so it's impossible to hit this code path without request smuggling. Even if you could hit it without request smuggling it would still be useless.
This attack does not require a MITM - the attacker would use a tool like Burp Suite to issue the (technically RFC-violating) HTTP request. The prefix injection happens because front-end places the attacker's request and the victim's request on the same HTTP/1.1 connection to the back-end, as shown in this diagram: https://portswigger.net/cms/images/9c/c1/4c32-article-http2-...
> isn't the suffix just ignored by the final remote
The back-end treats the suffix as the start of the next request, due to TCP buffering. The vast majority of servers have this kind of accidental pipelining support thanks to TCP.
