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

91–100 of 116 posts

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

#91

Post by phicoh »

londons_explore wrote: post #82
phicoh wrote: post #76

Earlier quoted context omitted.

Why does HTTP/2 force encryption? The HTTP/2 RFC (RFC 7540) also defines how to run HTTP/2 over plaintext. Terminating HTTP/2 over TLS on a web frontend and then HTTP/2 over plaintext to the application servers sounds like a viable model.

In practice HTTP/2 forces encryption. For example Amazons ALB docs say "Considerations for the HTTP/2 protocol version: The only supported listener protocol is HTTPS." [1] [1]: https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...

It make sense that internet facing clients and servers only support HTTP/2 over TLS. But that is different for internal connections or debug tools.

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

#92

Post by twic »

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.

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

#93

Post by hmsimha »

El_RIDO wrote: post #74
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."

You can partially answer this question yourself. So the issue can occur, when HTTP/2 requests get translated into HTTP/1.1 calls. Your HTTP calls stack from client to web app presumably looks something like this: Client → (HTTP/2) → Cloudflare ingress → (???) → Cloudflare egress → (???) → Your endpoint → (???) → Your web app On your endpoint (LB or webserver) logs you can check if the requests coming in from Cloudbee…

> But more importantly, you should investigate how your LB or webserver talks to the web app. In many cases that part won't be TLS encrypted and therefore on an HTTP/1.1 channel.

Or even HTTP 1.0 . I found out recently while inspecting some requests in the upstream server that nginx was using HTTP 1.0 after terminating TLS. I was dumbfounded that this was still the default.

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#pro...

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

#94

Post by twic »

nly wrote: post #64

I'm a bit confused how these attacks can be used. Inconsistencies between HTTP/1.1 and HTTP/2 allow for these behaviours but you still need to inject these malicious prefixes in to a user's request flow, right? Can you actually set the Content-Length header from a browser on a HTTP/2 request? And isn't the suffix just ignored by the final remote (or does this depend on HTTP/1.1 pipelining?)

The target's own front-end proxy acts as the man in the middle!

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

#95

Post by josefx »

phicoh wrote: post #90
josefx wrote: post #80

Earlier quoted context omitted.

> Yes, it is weird that a broken protocol translator results in blame for the newer protocol. From a look at the HTTP/2 spec. this protocol translation is an expected use case and explicitly results in several restrictions on the contents of HTTP/2 headers. So going by the HTTP/2 spec. at least some of those headers should have been rejected by a conformant front end and never made it into HTTP/1.

So how is a collection of broken translators the fault of HTTP/2? The title says 'The Sequel is Always Worse'. It is not HTTP/2 that is bad. It is translation to the, from a security point of view, problematic HTTP/1 that is the problem.

> It is translation to the, from a security point of view, problematic HTTP/1 that is the problem.

Parts of the HTTP/2 spec. specify what malformed headers look like, so this bug is almost entirely in the code not validating those HTTP/2 headers. This also isn't something that a few high school dropouts got wrong on their side projects, several major services got it wrong. Given that the spec. made at least some attempts to warn its implementers maybe future standards need a security section titled "Important: Why ignoring security advisory in standards is a bad idea".

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

#96

Post by pa9am »

londons_explore wrote: post #82
phicoh wrote: post #76

Earlier quoted context omitted.

Why does HTTP/2 force encryption? The HTTP/2 RFC (RFC 7540) also defines how to run HTTP/2 over plaintext. Terminating HTTP/2 over TLS on a web frontend and then HTTP/2 over plaintext to the application servers sounds like a viable model.

In practice HTTP/2 forces encryption. For example Amazons ALB docs say "Considerations for the HTTP/2 protocol version: The only supported listener protocol is HTTPS." [1] [1]: https://docs.aws.amazon.com/elasticloadbalancing/latest/appl...

My Apache server is fine speaking HTTP/2 over port 80:

  curl -v --http2 --http2-prior-knowledge http://localhost
  * Connected to localhost (::1) port 80 (#0)
  * Using HTTP2, server supports multi-use
  * Connection state changed (HTTP/2 confirmed)
  * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
  * Using Stream ID: 1 (easy handle 0x559a7c6545c0)
  > GET / HTTP/2
  > Host: localhost
  > user-agent: curl/7.74.0
  > accept: */*
  > 
  * Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
Sadly none of the services that I reverse proxy through Apache support HTTP/2..

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

#97

Post by brabel »

albinowax_ wrote: post #61

Hi, I'm the author - please let me know if you have any questions!

Just want to thank you for publishing this and taking the time to present it in such a clear manner.

As someone who has implemented HTTP/1.1 message parsing myself, it blows my mind how downgrade implementers could've made such basic mistakes as to not validate the contents of headers. The companies selling security software with these mistakes should be held accountable IMHO, as the attacks are so simple and so many that they've probably been exploited extensively in the wild, and similar attacks almost certainly continue to be.

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

#98

Post by dathinab »

stkdump wrote: post #41
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…

I guess this is more in line with the narrative that older protocols that people are more familiar with are somehow always better. That there is a hidden evil agenda for introducing something new. Or at least that we all need to pay a price for the sole benefit of a tech giant. It is a convenient narrative, which could be true, but it feels too easy a conclusion. Which makes it a good clickbait.

> It is a convenient narrative

It's also not he narrative the content of the article purses ;-)

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

#99

Post by ObscureScience »

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.

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

Am I misunderstanding?

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

#100

Post by chrismorgan »

simiones wrote: post #86
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…

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.
Post reply on HN