hacktricks/pentesting-web/http-connection-request-smuggling.md

HTTP 연결 요청 스머글링

htARTE (HackTricks AWS Red Team Expert)에서 **제로부터 영웅까지 AWS 해킹 배우기**

• 사이버 보안 회사에서 일하시나요? 회사를 HackTricks에서 광고하고 싶으신가요? 혹은 PEASS의 최신 버전에 액세스하거나 HackTricks를 PDF로 다운로드하고 싶으신가요? 구독 요금제를 확인해보세요!
• The PEASS Family를 발견해보세요, 저희의 독점 NFT 컬렉션
• 공식 PEASS & HackTricks 스웨그를 얻으세요
• 💬 Discord 그룹에 가입하거나 텔레그램 그룹에 참여하거나 트위터 🐦@carlospolopm를 팔로우하세요.
• 해킹 요령을 공유하고 싶으시다면 hacktricks repo 및 hacktricks-cloud repo 로 PR을 제출해주세요.

이 글은 다음 글의 요약입니다 https://portswigger.net/research/browser-powered-desync-attacks

연결 상태 공격

첫 번째 요청 유효성 검사

요청을 라우팅할 때, 역방향 프록시는 종종 허용된 호스트 목록을 기반으로 대상 백엔드 서버를 결정하기 위해 Host 헤더에 의존할 수 있습니다. 그러나 일부 프록시에서는 허용 목록이 연결의 초기 요청에서만 강제되는 취약점이 존재합니다. 결과적으로 공격자는 허용된 호스트로의 첫 번째 요청을 먼저 하고 동일한 연결을 통해 내부 사이트를 요청함으로써 이를 악용할 수 있습니다.

GET / HTTP/1.1
Host: [allowed-external-host]

GET / HTTP/1.1
Host: [internal-host]

첫 번째 요청 라우팅

일부 구성에서 프런트엔드 서버는 첫 번째 요청의 호스트 헤더를 사용하여 해당 요청의 백엔드 라우팅을 결정한 후, 동일한 클라이언트 연결에서 이후 모든 요청을 지속적으로 동일한 백엔드 연결로 라우팅할 수 있습니다. 이는 다음과 같이 설명할 수 있습니다:

GET / HTTP/1.1
Host: example.com

POST /pwreset HTTP/1.1
Host: psres.net

이 문제는 호스트 헤더 공격과 결합될 수 있으며, 비밀번호 재설정 독려 또는 웹 캐시 독려와 같은 공격을 통해 다른 취약점을 악용하거나 추가 가상 호스트에 무단 액세스할 수 있습니다.

{% hint style="info" %} 이러한 취약점을 식별하기 위해 HTTP Request Smuggler의 'connection-state probe' 기능을 활용할 수 있습니다. {% endhint %}

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

• 사이버 보안 회사에서 일하시나요? HackTricks에서 귀하의 회사를 홍보하고 싶으신가요? 또는 PEASS의 최신 버전에 액세스하거나 HackTricks를 PDF로 다운로드하고 싶으신가요? 구독 요금제를 확인하세요!
• The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션
• 공식 PEASS & HackTricks 스왜그를 얻으세요
• 💬 Discord 그룹에 가입하거나 텔레그램 그룹에 참여하거나 트위터 🐦@carlospolopm를 팔로우하세요.
• 해킹 요령을 공유하고 PR을 제출하여 hacktricks repo 및 hacktricks-cloud repo 를 따르세요.