HTTP 역방향 프록시의 보안 문제, FastCGI가 답일까?

기존 HTTP/1.1은 메시지 경계(Message Boundary)를 명확하게 정의하지 않아, HTTP Desync 공격(Desync Attacks)과 같은 보안 취약점에 노출될 위험이 높다. 특히, Discord 미디어 프록시에서 발생한 사례처럼, 공격자는 이러한 취약점을 이용하여 개인 정보 유출(Private Attachment)을 시도할 수 있다. FastCGI는 1996년부터 명확한 메시지 경계를 제공하여 이러한 문제를 근본적으로 해결한다.

HTTP는 프록시가 클라이언트의 IP 주소, 인증된 사용자 이름, 또는 클라이언트 인증서와 같은 신뢰할 수 있는 정보를 전달하는 데 어려움이 있다. X-Real-IP 헤더(Header)와 같은 방법을 사용하지만, 이는 공격자가 조작할 수 있는 취약점을 내포한다. FastCGI는 HTTP 헤더(Header)와 프록시에서 추가된 정보를 구분하여, 데이터 격리 아키텍처(Data Isolation Architecture)를 구현한다. 예를 들어, `REMOTE_ADDR`과 같은 표준 파라미터를 사용하여 클라이언트 IP 주소를 안전하게 전달한다.

FastCGI는 웹 소켓(WebSockets)을 지원하지 않는다는 단점이 있다. 하지만, WHATWG 스트림(Streams)을 활용하여 HTTP 요청을 통해 웹 소켓과 유사한 기능을 구현할 수 있다. 또한, FastCGI는 HTTP/2/3의 성능 향상을 활용할 수 있으며, 백 프레셔(Backpressure)를 지원한다. 하지만, 아직 요청 바디(Body) 스트리밍과 응답을 동시에 처리하는 기능은 지원하지 않는다.

커뮤니티에서는 FastCGI와 HTTP 간의 트레이드 오프(Trade-offs)에 대한 다양한 의견이 제시되었다. HTTP는 단순성으로 인해 널리 사용되지만, 보안 취약점에 취약하다는 단점이 있다. 반면, FastCGI는 보안 측면에서 우수하지만, 웹 소켓(WebSockets) 미지원 및 툴링(Tooling)의 부족함이 단점으로 지적된다. End-to-End 원칙(End-to-End Principle)과 최소 권한의 원칙(Principle of Least Privilege) 사이의 균형을 맞추는 것이 중요하다.