프록시와 앱 서버가 같은 HTTP 요청을 다르게 해석하면 어떤 문제가 생기며 어떻게 방어하나요?

요청 경계의 파싱이 앞단과 뒷단에서 다르면 한 연결의 바이트를 서로 다른 요청으로 나눠 해석할 수 있습니다. 이는 요청 혼입과 캐시·인가 경계 오류로 이어질 수 있어 모호한 메시지를 경계에서 거절해야 합니다.

동작 원리와 전제

Content-Length·Transfer-Encoding·중복 헤더·비정상 줄 구분과 HTTP 버전 변환의 계약을 확인합니다. 특정 문자열 제거보다 일관된 검증된 파서와 최신 프록시·서버를 사용합니다. 앞단만 정상이어도 뒷단이 다른 규칙으로 읽으면 문제가 남습니다.

선택과 실패 처리

불필요한 프로토콜 downgrade와 직접 backend 접근을 제한하고 모호한 요청을 전달하지 않게 합니다. 연결 재사용에서 이전 요청의 남은 바이트가 다음 요청에 섞이지 않도록 오류 시 연결 처리도 확인합니다.

구체적인 사례와 검증

이 문제는 정상적인 웹 API 단위 테스트가 직접 앱 서버만 호출하면 드러나지 않을 수 있습니다. 실제 CDN·로드밸런서·프록시·앱의 버전 변환 경로를 동일하게 구성한 테스트가 필요합니다. 모호한 헤더를 한 계층은 무시하고 다른 계층은 사용하는 차이를 확인하되, 공격 payload를 운영 사용자 연결에 보내는 식의 검증은 하지 않습니다. 파싱 오류 뒤 연결을 재사용하면 남은 바이트의 의미가 달라질 수 있어 연결 종료 정책도 확인합니다. 캐시 키·인증 경로와 결합될 때 피해가 커질 수 있으므로 경계 파서의 업데이트와 설정 일관성을 배포 검증에 포함합니다.

허가된 테스트 환경에서 실제 프록시 체인을 대상으로 요청 경계·오류 거절·연결 정리를 검증합니다. 운영 트래픽에 공격 재현을 무단 주입하지 않습니다. TLS 암호화나 애플리케이션 로그인은 파서 불일치를 해결하지 못하므로 전송·HTTP 경계의 별도 방어가 필요합니다.