#contentlength — Public Fediverse posts

Анатомия HTTP Request Smuggling

Чтобы разобраться в HTTP Request Smuggling, надо сначала честно ответить на вопрос, который в обычной жизни может прозвучать абсурдно: а как сервер понимает, где заканчивается один HTTP-запрос и начинается следующий? Кажется, что ответ очевиден — запрос это запрос, отправил и отправил. Но эта очевидность держится ровно до тех пор, пока запрос один и сервер один. Как только их становится много, а серверов в цепочке хотя бы два, выясняется, что «границу запроса» надо где-то явно записать, и способов записать её оказывается не один, и вот в этом зазоре и живёт вся уязвимость.

https://habr.com/ru/articles/1069538/

#http_request_smuggling #веббезопасность #ContentLength #пентест #backend #frontend #security

So yes, it turns out that though our communication partner pretends to accept HTTP/2, their API server adheres to HTTP/1.1 standards. And with HTTP/1.1, the #Java11 #HttpClient will send a #ContentLength header even if the payload is 0 bytes. Which is exactly what our communication partner expects. A bit weird, and sad.

It looks like #Java11 decided to completely omit the #contentLength header of an #HttpPost request if the content length equals 0 (zero). That's possible with HTTP/2, but not with HTTP/1.0 or 1.1.

The #RESTAPI server we talk to requires a content-length header even if the payload is empty. Does downgrading to HTTP/1.1 change the behavior of #JavaNetHttp? Does that get the header included?

Or do we have to override default header filtering?

Yesterday was the first time in years a remote #REST #API server required me to send the #ContentLength #requestHeader. The #HTTP component I was using, #HttpURLConnection by Sun, outright refused to set it.

I looked up the HTTP RFC: yes, it is called Content-Length, and yes, it's a count of 16-bit characters. And it can be used only if neither streaming nor chunking the contents. My code met those requirements.

What was going on?