HTTP 실행의 위험은 증가하지만 관리 가능

좋아하든 싫어하든, HTTP는 현대의 사실상 표준 애플리케이션 전송 프로토콜입니다. 우리는 그것을 어디에나 사용합니다. 이는 IP와 TCP만큼 널리 사용되며 거의 같은 목적을 갖습니다. 그 유일한 목표는 오늘날 비즈니스의 디지털 보물인 데이터를 전송하는 것입니다.

해당 데이터가 JSON인지, XML인지, URL로 인코딩되었는지는 중요하지 않습니다. 앱과 기기가 클라우드 및 온프레미스 데이터 센터의 서버 및 서비스와 통신하는 데 사용하는 것은 HTTP입니다.

그러나 IP와 TCP와 달리 HTTP는 텍스트 기반 프로토콜입니다. 매우 유연하며 이진 데이터에서 텍스트 데이터까지 다양한 데이터를 전송할 수 있습니다. 이를 통해 데이터를 스트리밍하고, 검색하고, 수집합니다.

공격자는 이를 자유롭게 사용합니다. 앞서 언급했듯이 이는 클라이언트가 서버에서 수행할 작업(HTTP '메서드')부터 요청하는 리소스(URI)까지, 어떤 종류의 콘텐츠를 허용할 수 있는지('Accept' 헤더)까지 모든 것을 지정하는 헤더 확장에 대한 규칙이 비교적 느슨한 텍스트 기반 프로토콜이기 때문입니다. 이러한 규칙은 확장성을 가능하게 하기 위해 느슨합니다.

예를 들어, X-Forwarded-For 헤더는 개발자가 원래 클라이언트 IP 주소를 '볼' 수 있도록 하는 수단으로 도입되었습니다. 특정 아키텍처(특히 중개자가 완전 프록시 역할을 하는 아키텍처)에서는 이 정보가 손실될 수 있습니다. 일부 애플리케이션에는 해당 데이터가 필요하므로 개발자(및 네트워크 공급업체)는 사용자 정의 헤더를 도입하여 HTTP 프로토콜을 확장했습니다. 이는 HTTP 사양의 일부로, 프로토콜을 변경하지 않고도 혁신과 새로운 동작 및 기능 도입이 가능합니다. 좋은 일이에요.

단, 그렇지 않은 경우는 제외합니다.

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

HTTP 헤더의 취약점을 악용하는 HTTP 관련 CVE의 작은 샘플은 다음과 같습니다.

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

Optionsbleed에 대한 참고사항 

옵션블리드는 가장 최근의 취약점 중 하나입니다. Apache HTTP 자체에 존재하기 때문에 언급합니다. Netcraft에서는 현재 "Apache가 현재 280만 대 이상의 웹 접속 컴퓨터에서 다양한 Apache httpd 버전과 파생 버전을 실행하고 있으며, 모든 웹 접속 컴퓨터의 42.8%를 차지하고 있다"고 추정하고 있으므로, 이의 취약점은 심각한 위험이 됩니다. 다행히도, 이 특정 취약점은 HTTP 헤더를 통해 발생하지만, .htaccess 파일 내에 잘못 구성된 Limits 지시어가 있어야만 가능합니다. Sophos의 이 게시물은 관심이 있다면 잔혹한 기술적 세부 사항에 대한 훌륭한 개요를 제공합니다 . 요약하자면, 잘못된 구성이 존재하는 경우 공격자는 HTTP 메서드 헤더를 통해 Apache의 취약점을 악용하여 서버가 다른 사람의 데이터를 "흘리도록" 강제할 수 있습니다.

이제 제가 말한 것을 모두 말했으니 이렇게 말할 수 있을 겁니다. 앱 보안은 스택입니다. 해당 스택에는 애플리케이션이 의존하는 플랫폼(따라서 프로토콜)이 포함됩니다. HTTP와 같습니다.

HTTP가 보안을 해치는 악용 사례로부터 보호하기 위해 더 나은 대책이 필요합니다. 데이터 유출이든, DoS이든, 원격 접속이든 그것이 중요한 게 아닙니다. 그것들은 모두 나쁜 영향입니다. HTTP가 점점 더 인기 있는 공격 영역이라는 점을 인식하는 데 더 노력해야 합니다. 텍스트 기반이라는 것은 클라이언트와 HTTP 서비스 간의 전체 상호작용이 사용자 입력 으로 분류되어야 함을 의미합니다.

그러면 위생 관리를 포함하는 보안 전략이 촉진되어야 합니다. 해당 입력의. 그렇습니다. 즉, 프로토콜을 적용하고 잠재적으로 취약한 HTTP 서버에 도달하기 전에 업스트림을 스크러빙한다는 뜻입니다.

즉 , 웹 애플리케이션 방화벽 이나 프로그래밍 가능 프록시는 모든 공개 HTTP 서비스 앞에 상주하여 들어오는 HTTP 요청을 적극적으로 스크러빙해야 합니다.

그 이유는 웹 플랫폼이 HTTP 헤더를 처리하는 방식, 즉 개발자에게 요청이 전달되기 전에 처리되는 방식 때문입니다. 따라서 플랫폼 수준의 취약점에 대해 개발자를 꼭 지목하고 안전하지 못한 코딩 관행을 비난할 수는 없습니다.

물론, 패치가 궁극적인 해결책입니다. (1) 취약점이 출시된 지 0일째 되는 날에 대해 알게 되고, (2) 패치가 출시된 지 0일째 되는 날에 제공되며, (3) 테스트되지 않은 패치를 프로덕션 시스템에 배포하는 데 문제가 없다고 가정합니다.

패치가 필요하다는 건 오해하지 마세요. 하지만 공개, 발견, 가용성, 적용 사이에는 격차가 있습니다. 그 틈에 위험이 숨어 있습니다. 즉, 매우 쉽게 악용될 수 있는 취약점이 당신에게 불리하게 사용될 위험이 있습니다.

가장 중요한 해결책은 패치를 준비하는 동안 악용을 방지하기 위해 스크립트나 서명 기반 스캐닝과 같은 즉각적인 해결 솔루션을 배포할 수 있는 시스템(플랫폼)을 마련하는 것입니다.

수신 데이터를 정리하고 프로토콜 정확성을 강제하는 것은 모든 기업 보안 정책의 일부가 되어야 합니다.

HTTP는 점점 더 위험해지고 있지만, 앱 보안이 스택이라는 점을 기억하고 스택의 각 계층에 보호 기능을 구축한다면 관리하기 쉽습니다.