H2.0 Request Smuggling (Request Smuggling via HTTP/2 Downgrades)

해당 게시글은 아래 3개의 페이지를 번역하여 정리하였습니다.

Advanced request smuggling

Advanced request smuggling | Web Security Academy

HTTP/2: The Sequel is Always Worse

HTTP/2: The Sequel is Always Worse

CL.0 request smuggling

CL.0 request smuggling | Web Security Academy

---

HTTP/2 Message Length

BurpSuite에서는 볼 수 없지만 HTTP/2 메시지는 여러 개로 나누어진 프레임을 통해 전송되며, 각 프레임의 앞에는 길이 필드가 존재합니다. 즉, 요청의 길이는 프레임들의 길이 합입니다.
일반적인 Request smuggling은 기본적으로 서로 다른 서버가 요청의 길이를 서로 다르게 해석하는 것을 이용하는 공격 기법인데, HTTP/2는 Content-Length 또는 Transfer-Encoding 요청 헤더를 사용하여 요청의 길이를 해석하는 것이 아니기 때문에 Request Smuggling에 방어책으로 언급되기도 하였습니다. 하지만 HTTP/2 다운그레이드를 이용한다면 HTTP/2에서도 Request Smuggling이 가능합니다.
 

HTTP/2 Downgrading

클라이언트와 프론트엔드 서버가 HTTP/2를 사용하지만, 프론트엔드 서버가 요청을 백엔드 서버에 전달하기 전에 동등한 HTTP/1.1로 다시 생성하는 것을 HTTP/2 다운그레이드라고 합니다. HTTP/2은 요청 헤더에 길이를 필수로 지정할 필요가 없습니다. 그렇기 때문에 다운그레이드하는 동안 Content-Length 헤더를 추가하거나 HTTP/2 요청의 Content-Length 헤더를 단순히 재사용합니다. 
HTTP/2 다운그레이드 시에 Content-Length 또는 Transfer-Encoding 헤더를 사용해야 하는데, 이로 인해 대표적으로 H2.TE와 H2.CL 두 가지 취약점이 발생합니다.
* 해당 게시글에서는 H2.0 Request Smuggling 취약점에 관련해서만 다루었습니다.

 

CL.0 Request Smuggling

H2.0 Request Smuggling을 이해하기 위해 CL.0 Request Smuggling을 먼저 언급하도록 합니다. CL.0 Request Smuggling은 백엔드 서버에서 요청의 Content-Length 헤더를 무시하는 경우에 발생하는 취약점입니다.
CL.0 Request Smuggling은 다른 요청이 포함된 첫번째 요청을 보낸 다음 일반적인 두번째 요청(GET / HTTP/1.1)을 보내고, 두번째 요청에 대한 응답이 첫번째 요청에서 Smuggling된 요청(GET /hopefully404 HTTP/1.1)에 영향을 받았는지 확인합니다.
 
Request

POST /vulnerable-endpoint HTTP/1.1
Host: vulnerable-website.com
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 34 

GET /hopefully404 HTTP/1.1
Foo: x
GET / HTTP/1.1
Host: vulnerable-website.com

 

Response

HTTP/1.1 200 OK

HTTP/1.1 404 Not Found

 

H2.0 Request Smuggling

HTTP/2 요청을 HTTP/1로 다운그레이드하는 웹 사이트이고, 백엔드 서버가 다운그레이드된 요청의 Content-Length 헤더를 무시하는 경우에도 CL.0 Request Smuggling과 동일한 취약점이 발생할 수 있습니다.

---

진단 예시 CASE

H2.0 Request Smuggling 취약점 식별 CASE입니다. 첫번째 요청(HTTP/2)에서 Content-Length를 제거하여 보냈기 때문에 HTTP/2 다운그레이드 시 Content-Length를 자체적으로 추가할 것으로 예상됩니다. 하지만 Content-Length 헤더가 무시되어 후속 요청을 보냈을 때 Smuggling된 요청이 정상 처리 된 것을 확인할 수 있습니다.