HTTP Request Smuggling

HTTP request smuggling이란 back-end 서버와 front-end 서버의 설정 차이로 인해 발생하는 취약점이다. 더 정확히는 각각의 서버에서 패킷의 길이를 계산하는 방식에 차이가 생겨 발생한다.

 

점점 서비스의 규모가 커져가고 클라우드 기반의 웹 애플리케이션을 도입하는 조직이 많아지면서 로드밸런싱이나 접근제어의 용이성과 같은 이유들로 위와 같은 구성(back-end <> front-end)이 보편화되어가고 있다. 그런데 이러한 구성에서 back-end 서버와 front-end 서버의 패킷 길이 계산 방식에 차이가 생기게 된다면 공격에 의해 백엔드 서버의 대기큐가 위변조 될 수 있다.

 

공격에 앞서, 패킷 제어를 위해 Transfer-Encoding(TE)과 Content-Length(CL) 헤더에 대한 이해가 필요하다. 각각의 헤더에 대한 더 자세한 설명은 공식 문서에 잘 쓰여있기 때문에 하단의 링크를 참고바란다. 간단히 설명하면 둘 다 body에 담긴 데이터의 길이 계산에 사용되는 header로 Content-Length는 body에 담긴 데이터의 길이를 header의 지시자에 표기하고 Transfer-Encoding은 body에 표기한다는 차이가 있다.

 

우선 일반적으로 볼 수 있는 Content-Length 헤더의 request 패킷 구조를 보면 다음과 같다.

POST / HTTP/1.1
Host: [host]
Content-Length: 8

qwer=123

Content-Length의 지시자로 body의 길이가 오는 것을 확인할 수 있다.

 

 

다음은 Transfer-Encoding 헤더를 사용하는 request 패킷 구조이다.

POST / HTTP/1.1
Host: [host]
Transfer-Encoding: chunked

8\r\n
qwer=123
0\r\n
\r\n

 

데이터의 길이\r\n+데이터+0\r\n\r\n 와 같은 구조로 나타나는 것을 확인할 수 있다. 여기서 '데이터의 길이'는 hex value로 표기한다는 점을 주의해야 한다.

 

그리고 문제는 이 두 가지 헤더를 동시에 사용했을때 발생한다.

POST / HTTP/1.1
Host: [host]
Content-Length: 6
Transfer-Encoding: chunked

0\r\n
\r\n
1

위와 같은 패킷을 전송했을 때 front-end 서버에서는 Content-Length 헤더를 기반으로 패킷을 처리하고 back-end 서버에서는 Transfer-Encoding 헤더를 기반으로 패킷을 처리한다고 했을 때 그 결과는 다음과 같다.

 

[back-end]

POST / HTTP/1.1
Host: [host]
Content-Length: 6   //무시됨
Transfer-Encoding: chunked

0\r\n
\r\n

1

front-end 서버는 Content-Length에 의해 패킷을 하나로 보고 back-end 서버에 전달하지만 back-end 서버는 이를 두 개의 패킷으로 간주해 위와 같이 요청이 둘로 나뉘게 되며 첫 번째 패킷에 대해서는 정상 응답을 보내지만 두 번째 패킷은 처리되지 않은 상태로 대기큐에 남아있다 다음 요청에 붙어서 전달된다. 그리고 이러한 방식의 취약점을 CL.TE (front = Content-Length, back-end = Transfer-Encoding) 라고도 한다.

 

단순한 취약점이지만 위와 같이 대기큐에 대한 위변조가 가능해짐으로써 front-end 서버의 각종 접근제어를 우회해 back-end 서버에 접근이 가능한 것은 물론 서비스 이용자를 대상으로 한 광범위한 공격(XSS, open redirect, sniffing...) 또한 가능하게 된다.

 

 

 

* 참고 *

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Content-Length

https://developer.mozilla.org/ko/docs/Web/HTTP/Headers/Transfer-Encoding

https://portswigger.net/research/http-desync-attacks-request-smuggling-reborn

https://portswigger.net/web-security/request-smuggling