Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

portswigger.net

Post reply on HN
Print view View original

101–110 of 116 posts

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#101

Post by tyingq »

twic wrote: post #92
dagenix wrote: post #35

The title seem very much anti-HTTP/2. However, unless I missed something huge, the vast majority, if not all, of the issues found relate to how hard it is to handle HTTP/1. And it seems kinda odd to blame HTTP/2 for HTTP/1 being difficult to implement. I'm certainly not trying to downplay the seriousness of these issues. But it seems like a equally (it not more) valid title might be something like "HTTP/1: Continues…

More than that, they relate to proxies. This sentence seems the crux to me: > If you're coding an HTTP/2 server, especially one that supports downgrading, enforce the charset limitations present in HTTP/1 - reject requests that contain newlines in headers, colons in header names, spaces in the request method, etc.

I imagine it also relates to things that really "proxies", but not normally thought of as such. Like PHP-FPM, wsgi, etc. Those are also doing protocol and header translation, and are very ubiquitous.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#102

Post by chrismorgan »

tptacek wrote: post #39
chrismorgan wrote: post #29

Earlier quoted context omitted.

These vulnerabilities are all from badly-written HTTP/2 → HTTP/1.1 translations. Most of them come from simple carelessness, rookie errors that should never have been made , dumping untrusted bytes from an HTTP/2 value into the HTTP/1.1 byte stream. This is security 101, straightforward injection attacks with absolutely nothing HTTP-specific in it. Some of them are a little more complex, requiring actual HTTP/2 and H…

It's tough to say that something is a "rookie error" when basically every serious professional team makes the same mistake. This broke apparently broke every AWS ALB, for instance.

I am genuinely astonished at the number of implementations and major players that are experiencing problems here. I’ve done plenty of HTTP/1 parsing (most significantly in Rust circa 2014) and some HTTP/2 parsing in its earlier draft days, and I can confidently and earnestly state that my code (then and now) would never under any circumstances be vulnerable to the ones I’m calling rookie errors, because I’m always going to validate the user input properly, including doing any subsequent validation necessary in the translation layer due to incompatibilities between the versions, because I know it’ll blow up on me if I don’t do these things. Especially when all of this stuff has already been pointed out in the HTTP/2 RFC’s Security Considerations section, which such sections you’re a fool to ignore when implementing an IETF protocol. The attacks that depend on content-length and transfer-encoding I’m quite not so confident about, though I believe that any of my code that I wrote then or that I would write now will be safe.

It’s quite possible that my attitude to these sorts of things has been warped by using Rust, which both encourages proper validation and makes it easier and more natural than it tends to be in languages like C or C++. I’d be curious to see figures of these sorts of vulnerabilities in varying languages—I strongly suspect that they occur vastly less in Rust code than in C or C++ code, even when they’re not directly anything to do with memory safety.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#103

Post by orra »

londons_explore wrote: post #83
orra wrote: post #69

Earlier quoted context omitted.

If you're running microservices, won't you be running them on a platform? If on Kubernetes, just install cert-manager. Or if using FaaS, your platform will already do TLS termination, no?

On kubernetes, cert-manager might get certificates for you, but you'll still need to make sure the application correctly reloads those certs (many application frameworks have no way to reload a certificate at runtime).

Your reverse proxy can handle the TLS termination. Nginx or Traifik or whatever.

Besides, if you're doing microservices, whatever is managing them should be able to restart them gracefully. No need for reload as such.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#104

Post by masklinn »

yxhuvud wrote: post #78
slivanes wrote: post #15

Earlier quoted context omitted.

I'm not seeing anything about this in nginx changelogs (or matching CVE's) either. Disabling http2 for now.

Why would an Apache bug show up in Nginx changelogs?

It would not, but given how widespread this issue is it seems likely nginx is vulnerable, and sensible to assume it is unless otherwise demonstrated.

It’s not like the feature is super useful in general.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#105

Post by withinboredom »

dagenix wrote: post #38
1vuio0pswjnm7 wrote: post #31

Earlier quoted context omitted.

I am not a "project", nor is my goal the support of online advertising as a "business model", it's information retrieval. I'm a web user. I "evaluated" HTTP pipelining 20 years ago; it has always worked great for me. It is not "fundamentall flawed" for my purposes. If it did not work, I suspect servers would have disabled it by default ages ago. They didn't. Today, I use it daily. The fact is, the majority of website…

Which servers / sites support HTTP/1.1 pipelining? This seems somewhat hard to lookup. https://en.wikipedia.org/wiki/HTTP_pipelining : says that proxies and web browsers mostly don't support it. It claims that it's easy for servers to support it, but provides no more details. It also mentions that curl removed pipelining support. https://forum.nginx.org/read.php?2,269248,269249#msg-269249 : Some person says that Ngin…

There’s a couple of golang servers that implement it to make their benchmarks look better.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#106

Post by simiones »

chrismorgan wrote: post #100
simiones wrote: post #86

Earlier quoted context omitted.

I would bet that a lot of these are not rookie errors, they are more akin to Spectre or Meltdown: inherently unsafe code that was considered a valuable risk for performance. In general, when writing a high performance middle box, you want to touch the data as little as possible: ideally, the CPU wouldn't even see most of the bytes in the message, they would just be DMA'd from the external NIC to the internal NIC. Thi…

No, as I said most of these are absolutely trivial injection attacks from not validating untrusted inputs, being used to trigger a class of vulnerability that has been well-documented since at least 2005.

My point is that the code is doing the most performant thing: sending the values from A to B with as little bit twiddling as possible. They almost certainly failed to even consider that there are different restrictions between the 2 protocols that could pose security issues.

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#107

Post by twic »

ObscureScience wrote: post #99
twic wrote: post #92

Earlier quoted context omitted.

More than that, they relate to proxies. This sentence seems the crux to me: > If you're coding an HTTP/2 server, especially one that supports downgrading, enforce the charset limitations present in HTTP/1 - reject requests that contain newlines in headers, colons in header names, spaces in the request method, etc.

What's wrong with it? It seems reasonable to protect yourself from header-injections allowed by a downgrade? Am I misunderstanding?

I don't think there's anything wrong with it, it's great advice!

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#108

Post by jpambrun »

albinowax_ wrote: post #58
dagenix wrote: post #35

The title seem very much anti-HTTP/2. However, unless I missed something huge, the vast majority, if not all, of the issues found relate to how hard it is to handle HTTP/1. And it seems kinda odd to blame HTTP/2 for HTTP/1 being difficult to implement. I'm certainly not trying to downplay the seriousness of these issues. But it seems like a equally (it not more) valid title might be something like "HTTP/1: Continues…

Hi, I'm the author. This paper is about HTTP/2, and the dangerous things that happen behind the scenes with HTTP/1 when people enable it. It's arguing that enabling HTTP/2 on your front-end makes your security worse if it's downgrading behind the scenes. This is a deliberately cheeky title, selected as a presentation title, rather than being aimed at social media where many people will read the title but not the cont…

My employer's mandatory proxy downgrades all HTTP/2, presumably so they can better inspect traffic. This results in a bad/slow experience on many sites. I wish HTTP/2 would not have downgrade at all so they would have to deal with it..

Re: HTTP/2-exclusive threats caused by implementation flaws and RFC imperfections

#110

Post by paco3346 »

paco3346 wrote: post #16

Really good explanations here. As a Cloudflare Enterprise customer I've opened a case with them to see if any of these vulnerabilities apply to their WAF. I was a bit surprised to see the article mention that Imperva's WAF was vulnerable. edit: Cloudflare has responded that "[they] are asking your question internally."

Our parent company is an Akamai Enterprise user. We've opened a case with them as well.
Post reply on HN