웹보안: HTTP Request Smuggling 취약점 분석 🕵️‍♂️🔒

안녕, 친구들! 오늘은 웹 보안의 세계로 여행을 떠나볼 거야. 특히 'HTTP Request Smuggling'이라는 아주 교활한 녀석에 대해 알아볼 거란 말이지. 이 녀석, 정말 골치 아픈 문제를 일으킬 수 있어서 우리가 잘 알아둬야 해. 그럼 함께 이 흥미진진한 여정을 시작해볼까? 🚀

잠깐! 이 글은 재능넷(https://www.jaenung.net)의 '지식인의 숲' 메뉴에서 볼 수 있어. 재능넷은 다양한 재능을 거래하는 플랫폼인데, 웹 보안 같은 전문적인 지식도 여기서 배울 수 있다니 정말 대단하지 않아? 😎

HTTP Request Smuggling이 뭐야? 🤔

자, 먼저 HTTP Request Smuggling이 뭔지 알아보자. 이름부터 좀 수상하지? '밀수'라니, 뭔가 몰래 숨겨서 보내는 것 같은 느낌이 들지 않아? 그래, 바로 그거야!

HTTP Request Smuggling은 웹 애플리케이션의 프론트엔드 서버와 백엔드 서버 사이에서 발생하는 취약점이야. 공격자가 교묘하게 HTTP 요청을 조작해서 서버들을 혼란에 빠뜨리는 거지. 마치 두 서버 사이에 몰래 뭔가를 끼워 넣는 것처럼 말이야. 😈

HTTP Request Smuggling은 서버들이 HTTP 요청의 경계를 다르게 해석하도록 만들어 공격을 수행해. 이게 무슨 말이냐고? 곧 자세히 설명할 테니 긴장하지 마!

왜 이런 일이 발생하는 걸까? 🧐

대부분의 현대 웹 애플리케이션은 여러 서버를 거쳐 요청을 처리해. 보통 프론트엔드 서버(예: 로드 밸런서, 리버스 프록시)와 백엔드 서버로 구성되지. 이 두 서버는 HTTP 요청을 주고받으면서 통신을 하는데, 여기서 문제가 발생할 수 있어.

왜냐하면 HTTP 프로토콜에는 요청의 끝을 나타내는 방법이 두 가지나 있거든. 바로 'Content-Length' 헤더와 'Transfer-Encoding' 헤더야. 이 두 가지 방법이 동시에 사용될 때, 서버마다 이를 해석하는 방식이 다를 수 있어. 그리고 바로 이 차이를 노리는 거지! 😱

HTTP Request Smuggling의 종류 🎭

HTTP Request Smuggling 공격에는 여러 종류가 있어. 주로 세 가지 유형으로 나눌 수 있지:

🔹 CL.TE (Content-Length.Transfer-Encoding)
🔹 TE.CL (Transfer-Encoding.Content-Length)
🔹 TE.TE (Transfer-Encoding.Transfer-Encoding)

각각의 유형에 대해 자세히 알아보자!

1. CL.TE (Content-Length.Transfer-Encoding) 공격 🎯

이 공격은 프론트엔드 서버가 Content-Length 헤더를 사용하고, 백엔드 서버가 Transfer-Encoding 헤더를 사용할 때 발생해. 어떻게 동작하는지 예를 들어 설명해줄게.

CL.TE 공격의 핵심은 프론트엔드 서버와 백엔드 서버가 요청의 끝을 다르게 해석하도록 만드는 거야. 프론트엔드는 Content-Length를 믿고, 백엔드는 Transfer-Encoding을 믿게 되지.

예를 들어, 다음과 같은 HTTP 요청을 보내보자:

POST / HTTP/1.1
Host: example.com
Content-Length: 6
Transfer-Encoding: chunked

0

G

여기서 뭐가 특이한지 보이니? Content-Length가 6이라고 되어 있어. 그런데 Transfer-Encoding도 chunked라고 되어 있지. 이렇게 되면 프론트엔드 서버는 Content-Length를 보고 요청의 길이가 6바이트라고 생각해. 반면에 백엔드 서버는 Transfer-Encoding: chunked를 보고 청크 인코딩 방식으로 해석하려고 해.

그러면 백엔드 서버는 '0'을 보고 요청이 끝났다고 생각하겠지? 그런데 뒤에 'G'가 남아있어. 이 'G'는 다음 요청의 시작으로 해석될 수 있어. 바로 이런 식으로 요청을 '밀수'하는 거야! 😲

2. TE.CL (Transfer-Encoding.Content-Length) 공격 🎯

이번엔 TE.CL 공격에 대해 알아보자. 이 공격은 CL.TE와는 반대로, 프론트엔드 서버가 Transfer-Encoding 헤더를 사용하고 백엔드 서버가 Content-Length 헤더를 사용할 때 발생해.

TE.CL 공격의 핵심은 Transfer-Encoding 헤더를 교묘하게 숨겨서 프론트엔드 서버만 인식하게 만드는 거야. 그러면 백엔드 서버는 Content-Length만 보고 요청을 해석하게 되지.

예를 들어, 다음과 같은 HTTP 요청을 보내보자:

POST / HTTP/1.1
Host: example.com
Content-Length: 4
Transfer-Encoding: chunked
Transfer-encoding: cow

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

여기서 특이한 점이 보이니? Transfer-Encoding 헤더가 두 번 나와. 하나는 정상적인 'chunked'고, 다른 하나는 이상한 'cow'야. 이렇게 하면 어떤 서버들은 첫 번째 Transfer-Encoding만 인식하고, 다른 서버들은 두 번째 것을 보고 이상하다고 생각해서 Transfer-Encoding을 무시할 수 있어.

프론트엔드 서버가 Transfer-Encoding: chunked를 인식하면, '5c'(16진수로 92)바이트의 청크로 해석하고 그 다음 '0'을 보고 요청이 끝났다고 생각해. 하지만 백엔드 서버는 Transfer-Encoding을 무시하고 Content-Length: 4만 보고 처음 4바이트('5c\r\n')만 첫 번째 요청의 본문으로 처리하고, 나머지는 두 번째 요청으로 해석하게 돼. 이렇게 해서 요청을 '밀수'하는 거지! 🕵️‍♂️

3. TE.TE (Transfer-Encoding.Transfer-Encoding) 공격 🎯

마지막으로 TE.TE 공격에 대해 알아보자. 이 공격은 프론트엔드와 백엔드 서버 모두 Transfer-Encoding 헤더를 사용하지만, 그 해석 방식이 다를 때 발생해.

TE.TE 공격의 핵심은 Transfer-Encoding 헤더를 약간 변형해서 한 서버는 인식하고 다른 서버는 인식하지 못하게 만드는 거야. 이렇게 하면 두 서버가 청크의 경계를 다르게 해석하게 돼.

예를 들어, 다음과 같은 HTTP 요청을 보내보자:

POST / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Transfer-Encoding: x

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

여기서도 Transfer-Encoding 헤더가 두 번 나와. 하나는 정상적인 'chunked'고, 다른 하나는 이상한 'x'야. 어떤 서버는 첫 번째 헤더만 처리하고, 다른 서버는 두 번째 헤더를 보고 Transfer-Encoding을 완전히 무시할 수 있어.

만약 프론트엔드 서버가 첫 번째 Transfer-Encoding: chunked를 사용하고, 백엔드 서버가 두 번째 Transfer-Encoding: x를 보고 혼란스러워해서 Transfer-Encoding을 무시한다면? 프론트엔드는 청크 인코딩으로 요청을 해석하지만, 백엔드는 그냥 일반 요청으로 해석하게 되는 거지. 이렇게 되면 백엔드 서버는 '5c'부터 시작하는 모든 내용을 하나의 요청 본문으로 처리하게 돼. 그 결과, 숨겨진 GPOST 요청이 백엔드 서버에 전달되는 거야! 😱

HTTP Request Smuggling의 위험성 😨

자, 이제 HTTP Request Smuggling이 어떻게 동작하는지 알았으니, 이게 왜 위험한지 알아보자. 이 공격이 성공하면 공격자는 다음과 같은 나쁜 짓들을 할 수 있어:

🔸 웹 캐시 오염: 악의적인 콘텐츠를 캐시에 저장해서 다른 사용자들에게 보여줄 수 있어.
🔸 요청 큐 오염: 다른 사용자의 요청을 가로채거나 변조할 수 있어.
🔸 세션 하이재킹: 다른 사용자의 세션을 훔칠 수 있어.
🔸 방화벽 우회: 보안 필터를 우회해서 악의적인 페이로드를 전달할 수 있어.
🔸 정보 유출: 서버의 내부 정보나 다른 사용자의 개인 정보를 빼낼 수 있어.

HTTP Request Smuggling 공격은 매우 위험해. 왜냐하면 이 공격은 서버 간의 통신을 교묘하게 조작해서 보안 메커니즘을 우회할 수 있기 때문이야. 게다가 이 공격을 탐지하고 방어하기가 쉽지 않아.

예를 들어, 공격자가 다음과 같은 요청을 보냈다고 생각해봐:

POST / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 6

0

GPOST /admin HTTP/1.1
Host: example.com
Content-Length: 10

x=1

이 요청이 성공적으로 '밀수'되면, 백엔드 서버는 '/admin' 경로로 요청을 받게 돼. 만약 이 경로가 관리자 전용 페이지라면? 공격자가 권한 없이 관리자 기능에 접근할 수 있게 되는 거야! 😱

HTTP Request Smuggling 취약점 탐지하기 🕵️‍♂️

자, 이제 이 교활한 공격을 어떻게 찾아낼 수 있는지 알아보자. HTTP Request Smuggling 취약점을 탐지하는 방법은 여러 가지가 있어. 하나씩 살펴볼게!

1. 시간 지연 기법 ⏱️

이 방법은 가장 기본적인 탐지 방법이야. 서버의 응답 시간을 관찰해서 취약점의 존재 여부를 추측하는 거지.

시간 지연 기법의 핵심은 의도적으로 처리 시간이 오래 걸리는 요청을 보내는 거야. 만약 취약점이 있다면, 이 요청이 다음 요청의 처리를 지연시킬 거야.

예를 들어, 다음과 같은 요청을 보내볼 수 있어:

POST / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4

1
A
X

이 요청 뒤에 바로 일반적인 요청을 보내. 만약 두 번째 요청의 응답이 평소보다 훨씬 늦게 온다면, 첫 번째 요청이 '밀수'되어 서버를 혼란스럽게 만들었을 가능성이 높아.

2. 오류 기반 탐지 🚫

이 방법은 서버의 오류 메시지를 이용해 취약점을 찾아내는 거야.

오류 기반 탐지의 핵심은 의도적으로 잘못된 형식의 요청을 보내서 서버의 반응을 관찰하는 거야. 서버마다 오류를 처리하는 방식이 다르기 때문에, 이를 통해 취약점의 존재를 추측할 수 있어.

예를 들어, 다음과 같은 요청을 보내볼 수 있어:

POST / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 6

0

G

이 요청은 의도적으로 Content-Length와 실제 본문의 길이를 불일치하게 만든 거야. 만약 서버가 이상한 오류 메시지를 반환하거나, 예상치 못한 방식으로 동작한다면 취약점이 있을 가능성이 높아.

3. 차이점 분석 🔍

이 방법은 서버의 다양한 응답을 비교 분석해서 취약점을 찾아내는 거야.

차이점 분석의 핵심은 다양한 형태의 요청을 보내고, 그에 대한 서버의 응답을 세밀하게 비교하는 거야. 응답 시간, 상태 코드, 헤더, 본문 등 모든 요소를 꼼꼼히 살펴봐야 해.

예를 들어, 다음과 같은 여러 요청을 보내고 그 응답을 비교해볼 수 있어:

1. 정상적인 요청
2. Content-Length만 있는 요청
3. Transfer-Encoding: chunked만 있는 요청
4. 둘 다 있지만 값이 불일치하는 요청
5. Transfer-Encoding 헤더를 약간 변형한 요청 (예: "Transfer-Encoding: chunked ")

이렇게 다양한 요청에 대한 서버의 반응을 비교 분석하면, 서버가 어떤 방식으로 요청을 처리하는지, 그리고 어떤 부분에서 취약점이 있을 수 있는지 파악할 수 있어.