본문 바로가기

모의해킹

HTTP Request Smuggling 취약점

#개요

Http Request Smuggling은 프론트 와 백엔드가 Http 요청의 경계를 다르게 해석하고 RFC7230을 따르지 않는 다양한 라이브러리 사용으로 인해 발생한다.

 

#취약점 발생 이유

RFC 2616에 따르면 Transfer-Encoding 헤더 필드와 Content-Length 헤더 필드가 모두있는 메시지가 수신되면 후자인 Content-Length는 무시되고 이를 Transfer-Encoding이 이를 대체되어 취약점이 발생할 수 있다.

 

예시) Transfer-Encoding: chunked

"Chunked" 방식에는 Content-Length 헤더가 존재하지 않고 대신 "Transfer-Encoding: Chuncked"라는 헤더로 요청한다.(0은 종료를 의미)

POST /search HTTP/1.1
Host: test.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

b
q=smuggling
0

 

#공격원리

 

#TE:CL

Content Length를 통해 프론트 쪽 서버에서는 본문의 길이가 24 바이트인 것처럼 작동하나 백엔드 쪽에서는 Transfer-Encoding에 부여된 chunked를 확인하고 조각조각 처리하는 중 "0"을 만나 데이터 처리를 종료하게 됩니다.

그럼 "0"이후로 표시된 smuggling 메시지는 처리되지 못하기 때문에 백엔드 버퍼에 잠시 기록된 채 다음 요청의 앞에 포함되어 전송될 때까지 대기하게 된다.

 

POST /category HTTP/1.1
Host: test.com
Content-Length: 24
Transfer-Encoding: chunked

0 -> processing
smuggling -> Back-End Stanby

 

#TE:TE

<Transfer-Encoding 혼돈화>
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding
: chunked

프론트와 백엔드 모두 Transfer-Encoding 헤더의 우선순위를 지정하여 처리할 경우 요청 헤더에 2개의 Transfer-Encoding을 삽입하여 smuggling할 수 있다. 이때 개행문자나 잘못된 값을 넣어 프론트랑 백엔드 둘중 하나가 이를 무시하도록 우회하는 것이다.

 

POST /category HTTP/1.1
Host: test.com
Content-Length: 24
Transfer-Encoding: chunked
Transfer-encoding: x

5
SPOST
0

 

HTTP Smuggling 공격에대해 정리는 마무리하며 추가적으로 이를 이용한 XSS 공격 , Redirect 공격도 가능하다.