HTTP 운영의 위험은 증가하고 있지만 관리할 수 있습니다

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

좋든 싫든 HTTP는 현대의 사실상 표준 애플리케이션 전송 프로토콜입니다. 우리는 어디서나 HTTP를 사용합니다. HTTP는 IP 및 TCP만큼이나 널리 쓰이며, 그 목적도 매우 유사합니다. HTTP의 유일한 목표는 오늘날 비즈니스의 디지털 금과도 같은 데이터의 전송입니다.

해당 데이터가 JSON이든 XML이든 URL 인코딩 형식이든 상관없습니다. 앱과 디바이스가 클라우드 및 온프레미스 데이터 센터의 서버와 서비스에 통신할 때 사용하는 것은 HTTP입니다.

하지만 IP 및 TCP와 달리 HTTP는 텍스트 기반 프로토콜입니다. 유연성이 매우 뛰어나 바이너리부터 텍스트까지 다양한 데이터를 전송할 수 있습니다. HTTP는 데이터를 스트리밍하고, 검색하고, 수집하는 데 사용됩니다.

앞서 언급했듯이 HTTP는 텍스트 기반 프로토콜이며, 클라이언트가 서버에 수행하기를 기대하는 작업(HTTP ‘메서드’)부터 요청하는 리소스(URI), 허용 가능한 콘텐츠 유형(‘Accept’ 헤더)에 이르기까지 모든 것을 지정하는 헤더의 확장에 관한 규칙이 상당히 느슨하기 때문에 공격자들이 이를 거리낌 없이 사용합니다. 이러한 규칙이 느슨한 이유는 확장성을 보장하기 위해서입니다.

예를 들어, X-Forwarded-For 헤더는 개발자가 원래 클라이언트의 IP 주소를 ‘확인’할 수 있도록 하기 위해 도입되었습니다. 특정 아키텍처, 특히 중간 장치가 완전 프록시로 작동하는 아키텍처에서는 이 정보가 유실될 수 있습니다. 일부 애플리케이션에는 이 데이터가 필요하므로 개발자와 네트워크 공급업체는 사용자 지정 헤더를 도입하여 HTTP 프로토콜을 확장했습니다. 이는 HTTP 사양의 일부로, 프로토콜을 변경하지 않고도 혁신을 이루고 새로운 동작과 기능을 도입할 수 있게 해 줍니다. 바람직한 기능입니다.

그렇지 않은 경우만 빼고요.

HTTP를 지원하는 서버의 개발자나 HTTP에 의존하는 애플리케이션의 보안을 담당하는 이들이 이러한 유연성을 고려하지 않는다면 문제가 됩니다.

다음은 HTTP 헤더의 취약점을 악용하는 HTTP 관련 CVE 중 일부입니다:

솔직히 말해, 알려진 CVE에서 HTTP 취약점을 검색하면 지나치게 긴 목록이 나오며(매우 다양한 공급업체와 소프트웨어가 포함됩니다), 여기에서 그 목록을 그대로 나열하지는 않겠습니다. 이러한 취약점 중 상당수는 일반적으로 HTTP 헤더를 악용할 때 발생합니다.

Optionsbleed에 대한 참고 사항

Optionsbleed는 비교적 최근에 발견된 취약점 중 하나입니다. 이 취약점을 특별히 언급하는 이유는 Apache HTTP 자체에 존재하기 때문입니다. Netcraft는 현재 “외부에 공개된 컴퓨터 280만 대 이상에서 다양한 버전과 파생 제품의 Apache httpd가 실행되고 있으며, 이는 외부에 공개된 전체 컴퓨터의 42.8%를 차지한다”고 추산합니다. 따라서 이 소프트웨어의 취약점은 중대한 위험이 됩니다. 다행히 이 특정 취약점은 HTTP 헤더를 통해 유발되지만, Limits 지시문이 .htaccess 파일 내에 잘못 구성되어 있어야 한다는 조건도 필요합니다. 자세하고 복잡한 기술적 내용이 궁금하다면 Sophos의 이 게시물에서 훌륭한 개요를 확인할 수 있습니다. 요약하자면, 이러한 잘못된 구성이 존재할 경우 공격자는 HTTP 메서드 헤더를 통해 Apache의 취약점을 악용하여 서버가 다른 누군가의 데이터를 ‘흘려보내도록’ 만들 수 있는 것으로 보입니다.

자, 제가 지금까지 이 모든 이야기를 한 것은 바로 이 말을 하기 위해서입니다. 앱 보안은 여러 계층으로 이루어진 스택입니다. 이 스택에는 애플리케이션이 의존하는 플랫폼(따라서 프로토콜도)이 포함됩니다. HTTP 같은 것 말이죠.

보안을 침해하는 데 HTTP가 악용되지 않도록 더 철저히 보호해야 합니다. 데이터 유출이든 DoS든 원격 액세스든 그 유형은 중요하지 않습니다. 모두 심각한 피해를 초래합니다. HTTP가 갈수록 널리 악용되는 공격 표면이라는 점을 더 분명히 인식해야 합니다. HTTP가 텍스트 기반이라는 것은 클라이언트와 HTTP 서비스 간의 모든 상호 작용을 사용자 입력으로 분류해야 한다는 의미입니다.

이는 결국 해당 입력값의 무해화를 포함하는 보안 전략을 채택하도록 유도해야 합니다. 즉, 잠재적으로 취약한 HTTP 서버에 도달하기 전에 업스트림에서 프로토콜을 강제하고 입력값을 정제해야 한다는 뜻입니다.

즉, 웹 애플리케이션 방화벽이나 프로그래밍 가능한 프록시를 외부에 공개된 모든 HTTP 서비스 앞단에 배치하여 수신되는 HTTP 요청을 적극적으로 정제해야 합니다.

그 이유는 웹 플랫폼이 HTTP 헤더를 처리하는 방식, 즉 요청이 개발자에게 전달되기도 전에 처리되는 방식에 있습니다. 따라서 플랫폼 수준의 취약성을 두고 무조건 개발자를 지목하며 안전하지 않은 코딩 관행을 탓할 수는 없습니다.

물론 궁극적인 해결책은 패치를 적용하는 것입니다. 단, (1) 취약점이 공개된 당일에 이를 인지하고, (2) 당일에 패치가 제공되며, (3) 충분히 테스트되지 않았을 가능성이 있는 패치를 운영 시스템에 배포하는 데 부담이 없어야 합니다.

오해는 마세요. 패치는 반드시 적용해야 합니다. 하지만 취약점 공개와 발견, 패치 제공, 실제 적용 사이에는 공백이 생깁니다. 바로 그 공백에 위험이 도사리고 있습니다. 악용하기 매우 쉬운 취약점이 여러분을 공격하는 데 사용될 위험입니다.

차선책은 악용을 방지하기 위해 스크립트나 시그니처 기반 검사와 같은 즉각적인 완화 조치를 배포할 수 있는 시스템(플랫폼)을 마련하는 것입니다. 이러한 조치는 패치를 준비하는 동안 적용할 수 있습니다.

정제하고 인바운드 데이터를 또한 프로토콜의 정확성을 보장하는 것은 모든 기업 보안 정책의 필수 요소여야 합니다.

HTTP의 위험성은 갈수록 커지고 있지만, 애플리케이션 보안이 여러 계층으로 이루어진 스택이라는 점을 기억하고 각 계층에 적절한 보호 조치를 마련한다면 충분히 관리할 수 있습니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물