제XNUMX자의 요청에 개입할 수 있는 프런트엔드-백엔드 시스템에 대한 공격

공개 콘텐츠 전송 네트워크, 로드 밸런서 또는 프록시를 통해 실행되는 사이트와 같이 프런트엔드-백엔드 모델을 사용하는 사이트에 대한 새로운 공격에 대한 세부 정보입니다. 이 공격을 통해 특정 요청을 보내 프런트엔드와 백엔드 사이의 동일한 스레드에서 처리되는 다른 요청의 내용에 끼어들 수 있습니다. 제안된 방법은 패치되지 않은 취약점의 존재를 알리는 프로그램의 일부로 연구자들에게 약 40만 달러를 지급한 PayPal 서비스 사용자의 인증 매개변수를 가로챌 수 있는 공격을 조직하는 데 성공적으로 사용되었습니다. 이 공격은 Akamai 콘텐츠 전송 네트워크를 사용하는 사이트에도 적용됩니다.

문제의 핵심은 프런트엔드와 백엔드가 종종 HTTP 프로토콜에 대해 서로 다른 수준의 지원을 제공하지만 동시에 여러 사용자의 요청을 공통 채널로 캡슐화한다는 것입니다. 요청을 수신하는 프런트엔드와 요청을 처리하는 백엔드를 연결하기 위해 수명이 긴 TCP 연결이 설정되며, 이를 통해 사용자 요청이 HTTP 프로토콜을 통해 분리되어 체인을 따라 차례로 전송됩니다. 요청을 분리하기 위해 헤더 "Content-Length"(요청에 포함된 데이터의 전체 크기 결정) 및 "전송 인코딩: 청크"("{size}\r\n{block}\r\n{size}\r\n{block}\r\n0" 형식으로 다양한 크기의 블록을 지정하여 데이터를 부분적으로 전송할 수 있습니다).

프런트엔드가 "Content-Length"만 지원하지만 "Transfer-Encoding: Chunked"(예: Akamai CDN에서 수행함)를 무시하거나 그 반대의 경우 문제가 발생합니다. Transfer-Encoding: 청크가 양쪽에서 지원되는 경우 HTTP 헤더 파서의 구현 기능을 공격에 사용할 수 있습니다. ", "전송 인코딩":[탭]청크", "X: X[\n]전송 인코딩: 청크", "전송 인코딩[\n]: 청크" 또는 "전송 인코딩: 청크" 및 백엔드가 이를 성공적으로 처리합니다.)

이 경우 공격자는 "Content-Length" 및 "Transfer-Encoding: 청크된" 헤더를 모두 포함하는 요청을 보낼 수 있지만 "Content-Length"의 크기는 청크된 체인의 크기와 일치하지 않습니다. 실제 값보다 작습니다. 프런트엔드가 "Content-Length"에 따라 요청을 처리하고 전달하고 백엔드가 "전송-인코딩: 청크"를 기반으로 블록이 완료될 때까지 기다리는 경우 "전송-인코딩: 청크"를 기반으로 한 데이터의 끝은 더 일찍 결정되고 요청의 나머지 부분은 공격자가 다음 요청의 시작 부분에 있게 됩니다. 공격자는 다음에 전송되는 다른 사람의 요청 시작 부분에 임의의 데이터를 첨부할 수 있습니다.

사용된 프런트엔드-백엔드 조합의 문제를 확인하려면 프런트엔드를 통해 다음과 같은 요청을 보낼 수 있습니다.

POST /HTTP/1.1 정보
호스트: example.com
전송 인코딩: 청크
콘텐츠 길이 : 4

1
Z
Q

백엔드가 요청을 즉시 처리하지 않고 청크 데이터의 최종 XNUMX 경계 블록이 도착할 때까지 기다리는 경우 문제가 발생합니다. 좀 더 완벽한 점검을 위해 준비된 프런트엔드에서 “Transfer-Encoding: 청크” 헤더를 숨기는 가능한 방법도 테스트하는 특수 유틸리티입니다.

실제 공격 수행은 공격받는 사이트의 기능에 따라 다릅니다. 예를 들어 Trello 웹 애플리케이션을 공격할 때 요청의 시작 부분을 바꿀 수 있습니다("PUT /1/members/1234... x=x&csrf와 같은 데이터 대체). =1234&username=testzzz&bio=cake”) 제XNUMX자 사용자의 원래 요청과 여기에 지정된 인증 쿠키가 포함된 메시지를 보냅니다. saas-app.com에 대한 공격의 경우 요청 매개변수 중 하나를 대체하여 응답의 JavaScript 코드를 대체할 수 있는 것으로 나타났습니다. redhat.com에 대한 공격의 경우 내부 핸들러를 사용하여 공격자의 웹 사이트("POST /search?dest=../assets/idx?redir=// 형식의 요청)로 리디렉션했습니다.[이메일 보호]/HTTP/1.1").

콘텐츠 전송 네트워크를 위한 방법을 사용하면 "Host:" 헤더를 대체하여 요청된 사이트를 간단하게 교체할 수 있게 되었습니다. 이 공격은 콘텐츠 캐싱 시스템의 콘텐츠를 손상시키고 캐시된 기밀 데이터를 추출하는 데에도 사용될 수 있습니다. 이 방법의 정점은 PayPal에 대한 공격 조직으로, 인증 중에 사용자가 보낸 비밀번호를 가로챌 수 있었습니다(iframe 요청은 paypal.com/us/gifts 페이지의 컨텍스트에서 JavaScript를 실행하도록 수정되었습니다. CSP(콘텐츠 보안 정책)가 적용되지 않은 경우).

흥미롭게도 2005년에는 제안 캐싱 프록시(Tomcat, squid, mod_proxy)에서 데이터를 스푸핑하거나 하나의 HTTP 세션 내에서 여러 "GET" 또는 "POST" 요청을 지정하여 방화벽 차단을 우회할 수 있는 본질적으로 유사한 요청 스푸핑 기술입니다.

출처 : opennet.ru