HTTP Request Smuggling / HTTP Desync Attack
Last updated
Last updated
AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)
웹 앱, 네트워크 및 클라우드에 대한 해커의 관점을 얻으세요
실제 비즈니스에 영향을 미치는 중요한 취약점을 찾아보고 보고하세요. 20개 이상의 맞춤형 도구를 사용하여 공격 표면을 매핑하고, 권한 상승을 허용하는 보안 문제를 찾아내며, 자동화된 익스플로잇을 사용하여 필수 증거를 수집하여 귀하의 노력을 설득력 있는 보고서로 전환하세요.
이 취약점은 프론트엔드 프록시와 백엔드 서버 간의 비동기화로 인해 공격자가 HTTP 요청을 전송할 수 있게 되며, 이 요청은 프론트엔드 프록시(로드 밸런서/리버스 프록시)에서는 단일 요청으로 해석되고 백엔드 서버에서는 2개의 요청으로 해석됩니다. 이로 인해 사용자는 자신의 요청 이후에 백엔드 서버에 도착하는 다음 요청을 수정할 수 있습니다.
메시지가 Transfer-Encoding 헤더 필드와 Content-Length 헤더 필드를 모두 포함하여 수신되면, 후자는 무시해야 합니다.
Content-Length
Content-Length 엔터티 헤더는 수신자에게 전송된 엔터티 본문의 크기를 바이트 단위로 나타냅니다.
Transfer-Encoding: chunked
Transfer-Encoding 헤더는 페이로드 본문을 사용자에게 안전하게 전송하는 데 사용되는 인코딩 형식을 지정합니다. 청크 전송 방식은 대량의 데이터가 일련의 청크로 전송됨을 의미합니다.
프론트엔드(로드 밸런서/리버스 프록시)는 content-length 또는 transfer-encoding 헤더를 처리하고, 백엔드 서버는 다른 하나를 처리하여 두 시스템 간의 비동기화를 유발합니다. 이는 공격자가 리버스 프록시에 하나의 요청을 전송할 수 있게 하여 백엔드 서버가 이를 2개의 서로 다른 요청으로 해석하게 할 수 있으므로 매우 치명적일 수 있습니다. 이 기술의 위험은 백엔드 서버가 주입된 2번째 요청을 다음 클라이언트에서 온 것처럼 해석하고, 그 클라이언트의 실제 요청이 주입된 요청의 일부가 된다는 사실에 있습니다.
HTTP에서 새 줄 문자는 2바이트로 구성됩니다:
Content-Length: 이 헤더는 요청 본문의 바이트 수를 나타내기 위해 10진수 숫자를 사용합니다. 본문은 마지막 문자에서 끝나는 것으로 예상되며, 요청의 끝에 새 줄이 필요하지 않습니다.
Transfer-Encoding: 이 헤더는 다음 청크의 바이트 수를 나타내기 위해 본문에서 16진수 숫자를 사용합니다. 청크는 새 줄로 끝나야 하지만 이 새 줄은 길이 표시기에 의해 계산되지 않습니다. 이 전송 방법은 크기 0의 청크로 끝나야 하며, 그 뒤에 2개의 새 줄이 와야 합니다: 0
Connection: 제 경험에 따르면 요청 스머글링의 첫 번째 요청에서는 **Connection: keep-alive**를 사용하는 것이 좋습니다.
이것을 Burp Suite로 악용하려고 할 때 **Update Content-Length 및 Normalize HTTP/1 line endings**를 리피터에서 비활성화하세요. 일부 도구는 새 줄, 캐리지 리턴 및 잘못된 content-length를 남용합니다.
HTTP 요청 스머글링 공격은 Content-Length (CL) 및 Transfer-Encoding (TE) 헤더를 해석하는 프론트엔드와 백엔드 서버 간의 불일치를 이용하여 모호한 요청을 전송함으로써 만들어집니다. 이러한 공격은 주로 CL.TE, TE.CL, 및 TE.TE의 형태로 나타날 수 있습니다. 각 유형은 프론트엔드와 백엔드 서버가 이러한 헤더를 우선시하는 방식의 고유한 조합을 나타냅니다. 취약점은 서버가 동일한 요청을 서로 다른 방식으로 처리하여 예상치 못한 결과를 초래하는 데서 발생합니다.
이전 표에 TE.0 기술을 추가해야 하며, CL.0 기술과 유사하지만 Transfer Encoding을 사용합니다.
프론트엔드 (CL): Content-Length 헤더를 기반으로 요청을 처리합니다.
백엔드 (TE): Transfer-Encoding 헤더를 기반으로 요청을 처리합니다.
공격 시나리오:
공격자가 Content-Length 헤더의 값이 실제 콘텐츠 길이와 일치하지 않는 요청을 보냅니다.
프론트엔드 서버는 Content-Length 값을 기반으로 전체 요청을 백엔드로 전달합니다.
백엔드 서버는 Transfer-Encoding: chunked 헤더로 인해 요청을 청크로 처리하며, 나머지 데이터를 별도의 후속 요청으로 해석합니다.
예제:
프론트엔드 (TE): Transfer-Encoding 헤더를 기반으로 요청을 처리합니다.
백엔드 (CL): Content-Length 헤더를 기반으로 요청을 처리합니다.
공격 시나리오:
공격자가 청크 크기(7b)와 실제 콘텐츠 길이(Content-Length: 4)가 일치하지 않는 청크 요청을 보냅니다.
프론트엔드 서버는 Transfer-Encoding을 존중하여 전체 요청을 백엔드로 전달합니다.
백엔드 서버는 Content-Length를 존중하여 요청의 초기 부분(7b 바이트)만 처리하고 나머지는 의도하지 않은 후속 요청의 일부로 남깁니다.
예제:
서버: 둘 다 Transfer-Encoding을 지원하지만, 하나는 난독화를 통해 이를 무시하도록 속일 수 있습니다.
공격 시나리오:
공격자가 난독화된 Transfer-Encoding 헤더가 있는 요청을 보냅니다.
어떤 서버(프론트엔드 또는 백엔드)가 난독화를 인식하지 못하는지에 따라 CL.TE 또는 TE.CL 취약점이 악용될 수 있습니다.
요청의 처리되지 않은 부분은 서버 중 하나에서 후속 요청의 일부가 되어 스머글링으로 이어집니다.
예제:
두 서버는 요청을 오직 Content-Length 헤더만을 기반으로 처리합니다.
이 시나리오는 일반적으로 스머글링으로 이어지지 않으며, 두 서버가 요청 길이를 해석하는 방식이 일치합니다.
예제:
Content-Length 헤더가 존재하고 0이 아닌 값을 가지며 요청 본문에 콘텐츠가 있음을 나타내는 시나리오를 의미합니다. 백엔드는 Content-Length 헤더를 무시하고(0으로 처리됨), 프론트엔드는 이를 파싱합니다.
이는 스머글링 공격을 이해하고 구성하는 데 중요하며, 서버가 요청의 끝을 결정하는 방식에 영향을 미칩니다.
예제:
이전과 유사하지만 TE를 사용합니다.
기술 여기에서 보고됨
예제:
이 기술은 초기 HTTP 데이터를 읽는 동안 웹 서버를 파괴할 수 있는 시나리오에서 유용하지만 연결을 닫지 않고 사용할 수 있습니다. 이렇게 하면 HTTP 요청의 본문이 다음 HTTP 요청으로 간주됩니다.
예를 들어, 이 글에서 설명된 바와 같이, Werkzeug에서는 일부 유니코드 문자를 전송하여 서버를 파괴할 수 있었습니다. 그러나 HTTP 연결이 Connection: keep-alive 헤더로 생성된 경우 요청의 본문은 읽히지 않으며 연결은 여전히 열려 있으므로 요청의 본문은 다음 HTTP 요청으로 처리됩니다.
홉-바이-홉 헤더를 악용하여 프록시에게 Content-Length 또는 Transfer-Encoding 헤더를 삭제하도록 지시하여 HTTP 요청 스머글링을 악용할 수 있습니다.
For more information about hop-by-hop headers visit:
hop-by-hop headersHTTP 요청 밀반입 취약점을 식별하는 것은 종종 타이밍 기법을 사용하여 달성할 수 있으며, 이는 조작된 요청에 대한 서버의 응답 시간을 관찰하는 데 의존합니다. 이러한 기법은 CL.TE 및 TE.CL 취약점을 감지하는 데 특히 유용합니다. 이러한 방법 외에도 이러한 취약점을 찾기 위해 사용할 수 있는 다른 전략과 도구가 있습니다:
Method:
애플리케이션이 취약한 경우, 백엔드 서버가 추가 데이터를 기다리게 하는 요청을 전송합니다.
Example:
Observation:
프론트엔드 서버는 Content-Length에 따라 요청을 처리하고 메시지를 조기에 차단합니다.
백엔드 서버는 청크 메시지를 기대하며 도착하지 않는 다음 청크를 기다려 지연이 발생합니다.
Indicators:
응답의 타임아웃 또는 긴 지연.
때때로 상세한 서버 정보와 함께 백엔드 서버에서 400 Bad Request 오류를 수신합니다.
Method:
애플리케이션이 취약한 경우, 백엔드 서버가 추가 데이터를 기다리게 하는 요청을 전송합니다.
Example:
Observation:
프론트엔드 서버는 Transfer-Encoding에 따라 요청을 처리하고 전체 메시지를 전달합니다.
백엔드 서버는 Content-Length에 따라 메시지를 기대하며 도착하지 않는 추가 데이터를 기다려 지연이 발생합니다.
Differential Response Analysis:
요청의 약간 변형된 버전을 전송하고 서버 응답이 예상치 못한 방식으로 다르게 나타나는지 관찰하여 파싱 불일치를 나타냅니다.
Using Automated Tools:
Burp Suite의 'HTTP Request Smuggler' 확장과 같은 도구는 다양한 형태의 모호한 요청을 전송하고 응답을 분석하여 이러한 취약점을 자동으로 테스트할 수 있습니다.
Content-Length Variance Tests:
실제 콘텐츠 길이에 맞지 않는 다양한 Content-Length 값을 가진 요청을 전송하고 서버가 이러한 불일치를 처리하는 방식을 관찰합니다.
Transfer-Encoding Variance Tests:
난독화되거나 잘못된 Transfer-Encoding 헤더를 가진 요청을 전송하고 프론트엔드 및 백엔드 서버가 이러한 조작에 어떻게 다르게 반응하는지 모니터링합니다.
타이밍 기법의 효과를 확인한 후, 클라이언트 요청을 조작할 수 있는지 확인하는 것이 중요합니다. 간단한 방법은 요청을 오염시키는 것을 시도하는 것입니다. 예를 들어, /에 대한 요청이 404 응답을 생성하도록 만드는 것입니다. 이전에 논의된 CL.TE 및 TE.CL 예제는 클라이언트가 다른 리소스에 접근하려고 할 때 404 응답을 유도하기 위해 클라이언트의 요청을 오염시키는 방법을 보여줍니다.
Key Considerations
요청 밀반입 취약점을 테스트할 때 다른 요청에 간섭하는 경우 다음 사항을 염두에 두십시오:
Distinct Network Connections: "공격" 요청과 "정상" 요청은 별도의 네트워크 연결을 통해 전송되어야 합니다. 두 요청 모두 동일한 연결을 사용하는 것은 취약점의 존재를 검증하지 않습니다.
Consistent URL and Parameters: 두 요청 모두 동일한 URL 및 매개변수 이름을 사용하도록 합니다. 현대 애플리케이션은 종종 URL 및 매개변수에 따라 특정 백엔드 서버로 요청을 라우팅합니다. 이를 일치시키면 두 요청이 동일한 서버에서 처리될 가능성이 높아지며, 이는 성공적인 공격을 위한 전제 조건입니다.
Timing and Racing Conditions: "정상" 요청은 "공격" 요청의 간섭을 감지하기 위해 다른 동시 애플리케이션 요청과 경쟁합니다. 따라서 "공격" 요청 직후에 "정상" 요청을 전송하십시오. 바쁜 애플리케이션은 결론적인 취약점 확인을 위해 여러 번의 시도가 필요할 수 있습니다.
Load Balancing Challenges: 로드 밸런서 역할을 하는 프론트엔드 서버는 요청을 다양한 백엔드 시스템에 분배할 수 있습니다. "공격" 요청과 "정상" 요청이 서로 다른 시스템에 도달하면 공격이 성공하지 않습니다. 이 로드 밸런싱 측면은 취약점을 확인하기 위해 여러 번의 시도가 필요할 수 있습니다.
Unintended User Impact: 공격이 다른 사용자의 요청(탐지를 위해 보낸 "정상" 요청이 아님)에 의도치 않게 영향을 미친다면, 이는 공격이 다른 애플리케이션 사용자에게 영향을 미쳤음을 나타냅니다. 지속적인 테스트는 다른 사용자에게 방해가 될 수 있으므로 신중한 접근이 필요합니다.
때때로 프론트엔드 프록시는 보안 조치를 시행하여 들어오는 요청을 면밀히 조사합니다. 그러나 이러한 조치는 HTTP 요청 밀반입을 이용하여 우회할 수 있으며, 이를 통해 제한된 엔드포인트에 대한 무단 접근이 가능합니다. 예를 들어, /admin에 접근하는 것이 외부에서 금지될 수 있으며, 프론트엔드 프록시는 이러한 시도를 적극적으로 차단할 수 있습니다. 그럼에도 불구하고 이 프록시는 밀반입된 HTTP 요청 내의 내장 요청을 검사하지 않을 수 있어 이러한 제한을 우회할 수 있는 허점을 남깁니다.
다음 예제는 HTTP 요청 밀반입을 사용하여 프론트엔드 보안 제어를 우회하는 방법을 보여줍니다. 특히 일반적으로 프론트엔드 프록시가 보호하는 /admin 경로를 목표로 합니다:
CL.TE Example
CL.TE 공격에서는 초기 요청에 Content-Length 헤더가 사용되고, 이후의 임베디드 요청은 Transfer-Encoding: chunked 헤더를 활용합니다. 프론트엔드 프록시는 초기 POST 요청을 처리하지만 임베디드 GET /admin 요청을 검사하지 않아 /admin 경로에 대한 무단 접근을 허용합니다.
TE.CL 예제
반대로, TE.CL 공격에서는 초기 POST 요청이 Transfer-Encoding: chunked를 사용하고, 이후의 임베디드 요청은 Content-Length 헤더를 기반으로 처리됩니다. CL.TE 공격과 유사하게, 프론트엔드 프록시는 밀반입된 GET /admin 요청을 간과하여, 의도치 않게 제한된 /admin 경로에 대한 접근을 허용합니다.
응용 프로그램은 종종 프론트엔드 서버를 사용하여 들어오는 요청을 수정한 후 백엔드 서버에 전달합니다. 일반적인 수정 사항은 클라이언트의 IP를 백엔드에 전달하기 위해 X-Forwarded-For: <IP of the client>와 같은 헤더를 추가하는 것입니다. 이러한 수정 사항을 이해하는 것은 보호 우회 또는 숨겨진 정보나 엔드포인트를 드러내는 방법을 알 수 있기 때문에 중요할 수 있습니다.
프록시가 요청을 어떻게 변경하는지 조사하기 위해, 백엔드가 응답에서 에코하는 POST 매개변수를 찾습니다. 그런 다음, 이 매개변수를 마지막에 사용하여 다음과 유사한 요청을 작성합니다:
이 구조에서는 후속 요청 구성 요소가 search= 뒤에 추가되며, 이는 응답에 반영되는 매개변수입니다. 이 반영은 후속 요청의 헤더를 노출시킵니다.
중첩 요청의 Content-Length 헤더를 실제 콘텐츠 길이에 맞추는 것이 중요합니다. 작은 값으로 시작하여 점진적으로 증가시키는 것이 좋습니다. 너무 낮은 값은 반영된 데이터를 잘라내고, 너무 높은 값은 요청이 오류를 발생시킬 수 있습니다.
이 기술은 TE.CL 취약점의 맥락에서도 적용 가능하지만, 요청은 search=\r\n0으로 종료되어야 합니다. 줄 바꿈 문자와 관계없이 값은 검색 매개변수에 추가됩니다.
이 방법은 주로 프론트엔드 프록시가 수행한 요청 수정 사항을 이해하는 데 사용되며, 본질적으로 자가 조사 역할을 합니다.
POST 작업 중에 특정 요청을 매개변수의 값으로 추가하여 다음 사용자의 요청을 캡처하는 것이 가능합니다. 다음과 같이 이를 수행할 수 있습니다:
다음 요청을 매개변수의 값으로 추가하면 후속 클라이언트의 요청을 저장할 수 있습니다:
이 시나리오에서, comment parameter는 공개적으로 접근 가능한 페이지의 게시물 댓글 섹션 내의 내용을 저장하기 위해 설계되었습니다. 따라서, 이후 요청의 내용은 댓글로 나타납니다.
그러나 이 기술에는 한계가 있습니다. 일반적으로, 이는 밀반입된 요청에서 사용된 매개변수 구분자까지의 데이터만 캡처합니다. URL 인코딩된 양식 제출의 경우, 이 구분자는 & 문자입니다. 이는 피해 사용자 요청에서 캡처된 내용이 첫 번째 &에서 중단됨을 의미하며, 이는 쿼리 문자열의 일부일 수도 있습니다.
또한, 이 접근 방식은 TE.CL 취약점에서도 유효하다는 점에 유의할 필요가 있습니다. 이러한 경우, 요청은 search=\r\n0으로 끝나야 합니다. 줄 바꿈 문자와 관계없이, 값은 검색 매개변수에 추가됩니다.
HTTP Request Smuggling은 Reflected XSS에 취약한 웹 페이지를 악용하는 데 활용될 수 있으며, 상당한 이점을 제공합니다:
대상 사용자와의 상호작용이 필요하지 않습니다.
HTTP 요청 헤더와 같이 일반적으로 접근할 수 없는 요청의 일부에서 XSS를 악용할 수 있습니다.
웹사이트가 User-Agent 헤더를 통해 반사된 XSS에 취약한 경우, 다음 페이로드는 이 취약점을 악용하는 방법을 보여줍니다:
이 페이로드는 취약점을 악용하기 위해 다음과 같이 구조화되었습니다:
Transfer-Encoding: chunked 헤더를 사용하여 밀반입의 시작을 나타내는 일반적인 POST 요청을 시작합니다.
다음으로 0을 따라, 청크된 메시지 본문의 끝을 표시합니다.
그런 다음, User-Agent 헤더에 <script>alert(1)</script> 스크립트를 주입하여 서버가 이 후속 요청을 처리할 때 XSS를 트리거하는 밀반입된 GET 요청이 도입됩니다.
밀반입을 통해 User-Agent를 조작함으로써, 페이로드는 정상 요청 제약을 우회하여 비표준이지만 효과적인 방식으로 반사된 XSS 취약점을 악용합니다.
사용자 콘텐츠가 **Content-type**이 **text/plain**인 응답에 반영되는 경우, XSS 실행을 방지합니다. 서버가 HTTP/0.9를 지원하면 이를 우회할 수 있을지도 모릅니다!
HTTP/0.9 버전은 1.0 이전의 버전으로, GET 동사만 사용하며 헤더로 응답하지 않고 본체만 응답합니다.
이 글에서는 요청 밀반입과 사용자의 입력에 응답하는 취약한 엔드포인트를 악용하여 HTTP/0.9로 요청을 밀반입했습니다. 응답에 반영될 매개변수는 **유효한 실행 가능한 JS 코드가 포함된 가짜 HTTP/1.1 응답(헤더와 본체 포함)**을 포함하므로 응답은 Content-Type이 text/html인 유효한 실행 가능한 JS 코드를 포함합니다.
응용 프로그램은 종종 리디렉션 URL의 Host 헤더에서 호스트 이름을 사용하여 한 URL에서 다른 URL로 리디렉션합니다. 이는 Apache 및 IIS와 같은 웹 서버에서 일반적입니다. 예를 들어, 후행 슬래시 없이 폴더를 요청하면 슬래시를 포함하도록 리디렉션됩니다:
결과:
비록 무해해 보이지만, 이 행동은 HTTP request smuggling을 사용하여 사용자를 외부 사이트로 리디렉션하는 데 조작될 수 있습니다. 예를 들어:
이 스머글된 요청은 다음에 처리된 사용자 요청이 공격자 제어 웹사이트로 리디렉션될 수 있습니다:
결과:
이 시나리오에서는 사용자의 JavaScript 파일 요청이 가로채집니다. 공격자는 응답으로 악성 JavaScript를 제공하여 사용자를 손상시킬 수 있습니다.
웹 캐시 오염은 프론트엔드 인프라의 콘텐츠를 캐시하는 어떤 구성 요소라도 있을 경우 실행될 수 있으며, 일반적으로 성능 향상을 위해 사용됩니다. 서버의 응답을 조작함으로써 캐시를 오염시킬 수 있습니다.
이전에 서버 응답을 변경하여 404 오류를 반환하는 방법을 관찰했습니다 (참조: 기본 예제). 유사하게, 서버를 속여 /static/include.js 요청에 대한 응답으로 /index.html 콘텐츠를 제공하도록 할 수 있습니다. 결과적으로, /static/include.js 콘텐츠는 캐시에서 /index.html의 콘텐츠로 대체되어 사용자가 /static/include.js에 접근할 수 없게 되며, 이는 서비스 거부(DoS)로 이어질 수 있습니다.
이 기술은 오픈 리다이렉트 취약점이 발견되거나 오픈 리다이렉트로의 사이트 내 리다이렉트가 있을 경우 특히 강력해집니다. 이러한 취약점을 이용하여 /static/include.js의 캐시된 콘텐츠를 공격자가 제어하는 스크립트로 대체할 수 있으며, 이는 업데이트된 /static/include.js를 요청하는 모든 클라이언트에 대한 광범위한 교차 사이트 스크립팅(XSS) 공격을 가능하게 합니다.
아래는 사이트 내 리다이렉트와 오픈 리다이렉트를 결합한 캐시 오염 활용의 예시입니다. 목표는 공격자가 제어하는 JavaScript 코드를 제공하기 위해 /static/include.js의 캐시 콘텐츠를 변경하는 것입니다:
Note the embedded request targeting /post/next?postId=3. This request will be redirected to /post?postId=4, utilizing the Host header value to determine the domain. By altering the Host header, the attacker can redirect the request to their domain (on-site redirect to open redirect).
After successful socket poisoning, a GET request for /static/include.js should be initiated. This request will be contaminated by the prior on-site redirect to open redirect request and fetch the content of the script controlled by the attacker.
Subsequently, any request for /static/include.js will serve the cached content of the attacker's script, effectively launching a broad XSS attack.
웹 캐시 오염과 웹 캐시 속임수의 차이점은 무엇인가요?
웹 캐시 오염에서는 공격자가 애플리케이션이 캐시에 악성 콘텐츠를 저장하도록 유도하고, 이 콘텐츠가 다른 애플리케이션 사용자에게 캐시에서 제공됩니다.
웹 캐시 속임수에서는 공격자가 애플리케이션이 다른 사용자의 민감한 콘텐츠를 캐시에 저장하도록 유도하고, 공격자는 이후 이 콘텐츠를 캐시에서 검색합니다.
The attacker crafts a smuggled request that fetches sensitive user-specific content. Consider the following example:
이 스머글링된 요청이 정적 콘텐츠(예: /someimage.png)를 위한 캐시 항목을 오염시키면, 피해자의 /private/messages의 민감한 데이터가 정적 콘텐츠의 캐시 항목 아래에 캐시될 수 있습니다. 결과적으로, 공격자는 이러한 캐시된 민감한 데이터를 검색할 수 있습니다.
이 게시물에서는 서버에 TRACE 메서드가 활성화되어 있다면 HTTP 요청 스머글링으로 이를 악용할 수 있을 가능성이 있다고 제안합니다. 이는 이 메서드가 서버에 전송된 모든 헤더를 응답 본문의 일부로 반영하기 때문입니다. 예를 들어:
죄송합니다, 요청하신 내용을 처리할 수 없습니다.
An example on how to abuse this behaviour would be to smuggle first a HEAD request. This request will be responded with only the headers of a GET request (Content-Type among them). And smuggle immediately after the HEAD a TRACE request, which will be reflecting the sent data.
As the HEAD response will be containing a Content-Length header, the response of the TRACE request will be treated as the body of the HEAD response, therefore reflecting arbitrary data in the response.
This response will be sent to the next request over the connection, so this could be used in a cached JS file for example to inject arbitrary JS code.
Continue following this post is suggested another way to abuse the TRACE method. As commented, smuggling a HEAD request and a TRACE request it's possible to control some reflected data in the response to the HEAD request. The length of the body of the HEAD request is basically indicated in the Content-Length header and is formed by the response to the TRACE request.
Therefore, the new idea would be that, knowing this Content-Length and the data given in the TRACE response, it's possible to make the TRACE response contains a valid HTTP response after the last byte of the Content-Length, allowing an attacker to completely control the request to the next response (which could be used to perform a cache poisoning).
Example:
이러한 응답을 생성합니다 (HEAD 응답에 Content-Length가 있어 TRACE 응답이 HEAD 본문의 일부가 되고 HEAD Content-Length가 끝나면 유효한 HTTP 응답이 밀반입되는 방식을 주목하세요):
HTTP 요청 스머글링 취약점을 발견했지만 이를 어떻게 악용할지 모르겠다면, 다음의 다른 악용 방법을 시도해 보세요:
HTTP Response Smuggling / Desync브라우저 HTTP 요청 스머글링 (클라이언트 측)
HTTP/2 다운그레이드에서의 요청 스머글링
https://hipotermia.pw/bb/http-desync-idor에서 가져옴
From: https://hipotermia.pw/bb/http-desync-account-takeover
https://github.com/bahruzjabiyev/t-reqs-http-fuzzer: 이 도구는 이상한 요청 스머글링 불일치를 찾는 데 유용한 문법 기반 HTTP 퍼저입니다.
웹 앱, 네트워크 및 클라우드에 대한 해커의 관점을 얻으세요
실제 비즈니스에 영향을 미치는 중요한 취약점을 찾아보고 보고하세요. 20개 이상의 맞춤형 도구를 사용하여 공격 표면을 매핑하고 권한 상승을 허용하는 보안 문제를 찾아 자동화된 익스플로잇을 사용하여 필수 증거를 수집하여 귀하의 노력을 설득력 있는 보고서로 전환하세요.
AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)
