HTTP request smuggling(HTTP 요청 밀수)
HTTP request smuggling(HTTP 요청 밀수)란 ?
웹 사이트가 한 명 이상의 사용자로부터 받은 일련의 HTTP요청을 처리하는 방식을 방해하는 기술
request smuggling 취약점은 공격자가 보안 제어를 우회하고 중요한 데이터에 대한 무단 액세스 권한을 얻고 다른 어플리케이션 사용자를 직접 손상시킬 수 있다.
HTTP request smuggling(HTTP 요청 밀수) 공격에서는 어떤일이 발생하나요?
오늘날의 웹 어플리케이션은 사용자와 궁극적인 애플리케이션 로직 사이에 HTTP 서버 체인을 자주 사용
사용자는 프론트 엔드 서버(로드 밸런서 또는 리버스 프록시)에 요청을 보내고 이 서버 는 요청을 하나 이상의 백 엔드 서버로 전달
이러한 유형의 아키텍처는 최신 클라우드 기반 애플리케이션에서 점점 보편화되고 경우에 따라 피할 수 없는 경우도 있음
프론트 엔드 서버가 백엔드 서버에 HTTP 요청을 전달할 때 일반적으로 동일한 백엔드 네트워크 연결을 통해 여러 요청을 보냄
(효율적이고 성능이 좋기 때문에)
프로토콜은 매우 간단합니다. HTTP 요청이 차례로 전송되고 수신 서버는 HTTP 요청 헤더를 구문 분석하여 한 요청이 끝나고 다음 요청이 시작되는 위치를 결정함.
=> 이 상황에서 프론트엔드와 백엔드 시스템이 요청 간의 경계에 대해 동의하는것이 중요함.
(그렇지 않을 경우, 공격자가 프론트엔드 및 백엔드 시스템에서 다르게 해석되는 모호한 요청을 보낼 수 있음)
=> 여기서 공격자는 프론트 엔드 요청의 일부가 백엔드 서버에서 다음 요청의 시작으로 해석되도록 함.
이는 효과적으로 다음 요청 앞에 추가되므로 애플리케이션이 해당 요청을 처리하는 방식을 방해할 수 있음.
(이는 요청 밀수 공격이며 치명적인 결과를 초래할 수 있음)
HTTP request smuggling 취약점은 어떻게 발생할까요?
- 대부분의 HTTP 요청 스머글링 취약점은 HTTP 사양이 요청이 끝나는 위치를 지정하는 두가지 다른 방법
(헤더 Content-Length와 Transfer-Encoding 헤더)을 제공하기 때문에 발생함.
POST /serach HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Lenght: 11
q=smuggling헤더 Transfer-Encoding는 메시지 본문이 청크 인코딩을 사용하도록 지정하는 데 사용할 수 있다
=> 이는 메시지 본문에 하나 이상의 데이터 청크가 포함되어 있음을 의미.
각 청크는 바이트 단위의 청크 크기(16진수로 표시), 개행 문자, 청크 내용으로 구성
메시지는 청크 크기가 0으로 종료됩니다.
POST /serach HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
b
q=smuggling
0
많은 보안 테스터는 다음 두 가지 이유로 청크 분할 인코딩이 HTTP 요청에 사용될 수 있다는 사실을 인식하지 못합니다.
- Burp Suite는 청크 분할 인코딩을 자동으로 풀어 메시지를 보다 쉽게 보고 편집할 수 있도록 합니다.
- 브라우저는 일반적으로 요청에서 청크 분할 인코딩을 사용하지 않으며 일반적으로 서버 응답에서만 볼 수 있습니다.
HTTP 사양은 HTTP 메시지의 길이를 지정하는 두 가지 다른 방법을 제공하므로 단일 메시지가 두 방법을 동시에 사용하여 서로 충돌하는 것이 가능함.
Content-Length HTTP 사양은 및 Transfer-Endoing 헤더가 모두 있는경우, Content-Length 헤더를 무시해야 한다고 명시하여 이 문제를 방지하려고 시도함. 이는 하나의 서버만 실행 중일 때 모호성을 피하기에 충분할 수 있지만 두 개 이상의 서버가 함께 연결된 경우에는 그렇지 않다. 이 상황에서 두 가지 이유로 문제가 발생할 수 있다.
- Transfer-Encoding 일부 서버는 요청에서 헤더를 지원하지 않음
- 헤더가 어떤 식으로든 난독화되면 헤더를 지원하는 일부 서버가 Transfer-Encoding 헤더를 처리하지 않도록 유도할 수 있음.
프론트엔드 및 백엔드 서버가 (아마도 난독화된) 헤더와 관련하여 다르게 동작하는 경우 Transfer-Encoding 연속 요청 간의 경계에 대해 동의하지 않아 요청 스머글링 취약점이 발생할 수 있음.
HTTP 요청 밀수 공격을 수행하는 방법?
Content-Length 요청 밀수 공격은 헤더와 헤더를 모두 단일 HTTP 요청에 배치 Transfer-Encoding 하고 이를 조작하여 프론트 엔드 및 백엔드 서버가 요청을 다르게 처리하도록 하는 것입니다. 이것이 수행되는 정확한 방법은 두 서버의 동작에 따라 다릅니다.
- CL.TE: 프론트엔드 서버는 Content-Length 헤더를 사용하고 백엔드 서버는 Transfer-Encoding 헤더를 사용
- TE.CL: 프론트엔드 서버는 Transfer-Encoding 헤더를 사용하고 백엔드 서버는 Content-Length 헤더를 사용
- TE.TE: 프론트엔드 및 백엔드 서버 모두 헤더를 지원 Transfer-Encoding 하지만 어떤 방식으로든 헤더를 난독화하여 서버 중 하나가 헤더를 처리하지 않도록 유도할 수 있음.
CL.TE 취약점
프론트엔드 서버는 Content-Length 헤더를 사용하고 백엔드 서버는 Transfer-Encoding 헤더를 사용함
| POST / HTTP/1.1 HOST: vulneralbe-website.com Content-Length: 13 Transfer-Encoding: chunked 0 SMUGGLED |
프론트 엔드 서버는 Content-Length 헤더를 처리하고 요청 본문이 의 끝까지 13바이트 길이임을 확인함
SMUGGLED: 이 요청은 백엔드 서버로 전달됨.
백엔드 서버는 Transfer-Encoding 헤더를 처리하므로 메시지 본문을 청크 분할 인코딩을 사용하는 것으로 취급합.
길이가 0이라고 명시된 첫 번째 청크를 처리하므로 요청을 종료하는 것으로 처리됨.
다음 바이트는 SMUGGLED 처리되지 않은 상태로 남아 있으며 백엔드 서버는 이를 시퀀스의 다음 요청 시작으로 처리함.
TE.CL 취약점
프론트엔드 서버는 Transfer-Encoding 헤더를 사용하고 백엔드 서버는 Content-Length 헤더를 사용함
| POST / HTTP/1.1 HOST: vulnerable-website.com Content-Length: 3 Transfer-Encoding: chunked 8 SMUGGLED 0 |
* 메모
Burp Repeater를 사용하여 이 요청을 보내려면 먼저 Repeater 메뉴로 이동하여 "Update Content-Length" 옵션이 선택 해제되어 있는지 확인해야 합니다.
\r\n\r\n 마지막 뒤에 오는행 시쿼스를 포함해야합니다 0.
프론트 엔드 서버는 Transfer-Encoding 헤더를 처리하므로 메시지 본문을 청크 분할 인코딩을 사용하는 것으로 처리함.
다음 줄의 시작 부분까지 길이가 8바이트인 첫 번째 청크를 처리함. SMUGGLED 길이가 0인 두 번째 청크를 처리하므로 요청을 종료하는 것으로 처리됨. 이 요청은 백엔드 서버로 전달됩니다.
백엔드 서버는 Content-Length 헤더를 처리하고 요청 본문이 다음 라인의 시작 부분까지 길이가 3바이트인지 확인합니다.
8로 시작하는 다음 바이트는 SMUGGLED 처리 되지 않은 상태로 남아 있으며 백엔드 서버는 이를 시퀀스의 다음 요청 시작으로 처리함.
TE.TE 동작 : TE 헤더 난독화
프론트엔드와 백엔드 서버 모두 Transfer-Encoding 헤더를 지원하지만 어떤 방식으로든 헤더를 난독화하여 서버 중 하나가 헤더를 처리하지 않도록 유도할 수 있습니다.
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 |
이러한 각 기술에는 HTTP 사양에서 미묘하게 벗어난 부분이 포함됩니다.
프로토콜 사양을 구현하는 실제 코드는 절대 정밀도로 프로토콜 사양을 준수하는 경우가 거의 없으며 구현에 따라 사양의 다양한 변형을 허용하는 것이 일반적입니다. Transfer-Encoding TE.TE 취약점을 발견 하려면 프론트엔드 또는 백엔드 서버 중 하나만 처리하고 다른 서버에서는 무시하는 헤더의 일부 변형을 찾아야합니다.
난독화된 헤더를 처리하지 않도록 유도할 수 있는 것이 프론트엔트인지 백엔드 서버인지에 따라 Transfer-Encoding 나머지 공격은 이미 설명한 CL.TE 또는 TE.CL 취약점과 동일한 형태를 취합니다.
참고: