Web14: HTTP 프로토콜의 보안 문제

이 문서에서는 RFC 7230 및 RFC 7231 두 문서에서 제기된 HTTP 프로토콜 의 몇 가지 보안 문제를 제시합니다 . 특정 오류에 대한 문서의 예는 OWASP에서 참조됩니다.

1. 중간요인으로 인한 위험

HTTP를 사용하면 중개자를 사용하여 일련의 연결을 통해 요청에 응답할 수 있습니다. 프록시, 게이트웨이, 터널이라는 세 가지 일반적인 중개 요소가 있습니다.

요청이나 응답은 A, B, C 지점을 거쳐야 합니다. 사용자나 조직의 개인정보 등 전송되는 민감한 정보에 접근할 수 있습니다. 중개자가 보안과 개인 정보 보호에 주의를 기울이지 않으면 광범위한 잠재적인 공격이 발생할 수 있습니다.

시스템 개발자와 개발자는 시스템 설계, 코딩 및 배포 프로세스 중에 개인 정보 보호 및 보안 요소를 고려해야 합니다.

사용자는 신뢰할 수 없는 프록시나 게이트웨이를 사용할 때의 위험성을 인식해야 합니다.

2. 응답 분할

응답 분할(CRLF 주입이라고도 함)은 널리 사용되는 웹 공격 기술입니다. 공격자는 일부 요청 매개변수에 인코딩된 데이터를 전송합니다. 이 데이터는 응답 헤더의 특정 필드에서 디코딩되고 반복됩니다.

이 데이터가 응답의 끝을 나타내는 기호이고 후속 응답이 시작되면 원래 응답은 두 개로 분할되고 두 번째 응답의 내용은 공격자가 제어하게 됩니다. 그런 다음 공격자는 동일한 영구 연결 내에서 또 다른 요청을 만들고 수신자(중개자 포함)를 속여 이 두 번째 응답이 두 번째 요청에 대한 응답이라고 믿도록 할 수 있습니다.

3. 밀수요청

요청 밀수는 원래 요청에 추가된 겉보기에 무해해 보이는 요청을 숨기기 위해 다양한 유형의 서버에 의한 요청 처리의 차이를 이용하는 기술입니다.

다음 예를 고려해 보겠습니다.

POST 요청의 헤더에 두 개의 서로 다른 값을 가진 두 개의 "Content-length" 필드가 포함되어 있다고 가정합니다. 일부 서버(IIS 및 Apache)는 이 요청을 거부하지만 다른 서버는 거부합니다. 예를 들어 SunONE W/S 6.1은 Content-length 필드를 먼저 사용하고 sunONE Proxy 3.6은 Content-length 필드를 두 번째로 사용합니다.

SITE가 SunONE 프록시 뒤에 있는 SunONE W/S의 DNS라고 가정하면 SunONE W/S에 Poison.html 파일이 있습니다. 두 서버 간의 처리 불일치를 기반으로 HTTP 요청 제안을 활용하는 방법은 다음과 같습니다.

[라인 10을 제외하고 각 라인은 CRLF("")로 끝납니다.]

Proxy 서버를 통해 W/S에 요청이 전송되면 어떤 일이 발생하는지 살펴보겠습니다. 먼저 프록시는 1~7행(파란색)의 요청을 분석하고 두 개의 Content-Length 필드를 발견합니다. 위에서 언급한 것처럼 첫 번째 필드를 무시하고 요청 본문의 길이가 44바이트임을 이해합니다. 따라서 8~10행의 데이터를 첫 번째 요청 본문으로 처리합니다(8~10행의 데이터 길이는 정확히 44바이트입니다). 그런 다음 프록시는 11~14행(빨간색)을 클라이언트의 두 번째 요청으로 분석합니다.

이제 위의 데이터가 프록시에서 전달될 때 W/S가 어떻게 해석하는지 살펴보겠습니다. 프록시와 달리 W/S는 첫 번째 Content-Length 필드를 사용하고 이를 다음과 같이 해석합니다. 첫 번째 요청에는 본문이 없으며 두 번째 요청은 8행에서 시작합니다(W/S는 11행부터 값으로 구문 분석합니다). Bla 필드의).

다음으로 응답이 클라이언트에 어떻게 반환되는지 살펴보겠습니다. W/S가 이해하는 요청은 "POST /foobar.html"(1행) 및 "GET /poison.html"(8행)이므로 foobar 페이지의 내용과 함께 클라이언트 2 응답을 보냅니다. HTML과 Poison.html. 프록시는 이러한 2개의 응답이 2개의 요청, 즉 "POST /foobar.html"(1번째 줄에서) 및 "GET /page_to_poison.html"(11번째 줄)에 해당한다는 것을 이해합니다. 프록시는 URL "page_to_poison.html"(캐시 중독)에 해당하는 Poison.html 페이지의 콘텐츠를 캐시합니다. 거기에서 클라이언트가 "page_to_poison.html"을 요청하면 Poison.html 페이지의 콘텐츠를 받게 됩니다.

4. 파일 경로 기반 공격

웹 서버는 로컬 파일 시스템을 사용하여 URI의 파일 이름과 서버의 실제 리소스 매핑을 관리하는 경우가 많습니다. 대부분의 파일 시스템은 악성 파일 경로로부터 보호하도록 설계되지 않았습니다. 따라서 서버는 중요한 시스템 파일에 대한 액세스를 피해야 합니다.

예를 들어 UNIX, Microsoft Windows 및 기타 여러 운영 체제에서는 ".."를 경로 요소로 사용하여 현재 파일/디렉터리보다 한 수준 위의 디렉터리를 나타냅니다. 적절한 입력 제어 및 인증이 없으면 해당 파일/폴더를 가리키는 경로를 입력하여 시스템의 민감한 파일/폴더에 액세스할 수 있습니다.

5. 공격 유형: 명령 주입, 코드 주입, 쿼리 주입

[웹 서버는 종종 시스템 명령 및 데이터베이스 쿼리를 실행하기 위해 URI의 매개변수를 입력으로 사용합니다. 그러나 요청으로 수신된 데이터를 항상 신뢰할 수는 없습니다. 공격자는 요청의 구성 요소(예: 메서드, 헤더의 필드, 본문 등)를 생성 및 수정하여 시스템 명령을 실행하고 데이터베이스를 쿼리할 수 있습니다.

예를 들어 SQL 주입은 웹 서버가 SQL 쿼리의 일부인 URI에서 매개 변수를 수신하는 일반적인 공격입니다. 따라서 공격자는 데이터베이스를 훔치거나 방해하기 위해 웹 서버를 속여 불법 SQL 쿼리를 실행할 수 있습니다.
일반적으로 사용자가 제출한 데이터는 서버에서 작업을 수행하는 데 직접 사용되어서는 안 됩니다. 이러한 데이터는 유효한 것과 유효하지 않은 것을 정의하는 필터를 거쳐 불필요한 데이터를 제거해야 합니다.

6. 개인정보의 공개

클라이언트에는 사용자가 서버와 상호 작용하기 위해 제공한 정보(예: 사용자 이름, 비밀번호, 위치, 이메일 주소 등)와 사용자의 웹 검색 활동에 대한 정보(기록, 북마크, 등.). 구현 시 이러한 개인정보가 노출될 수 있는 점을 방지하는 데 주의를 기울여야 합니다.

7. URI에서 민감한 정보 공개

URI는 기본적으로 모든 사용자와 공유되도록 설계되었으며 보안이 보장되지 않습니다. URI는 웹사이트의 소스 코드에 표시되는 경우가 많으며 보호 메커니즘 없이 북마크에 저장됩니다. 따라서 URI에 민감한 정보, 개인 정보 등이 포함되어 있으면 안전하지 않습니다.

개인 정보는 URI에 표시되므로 GET 메서드를 사용하여 서버에 전송하지 마세요. 대신 POST 메서드를 사용하세요.

8. 사용된 소프트웨어 정보 공개

헤더의 User-Agent, Via, Server 필드는 일반적으로 보낸 사람이 사용하는 소프트웨어에 대한 정보를 제공합니다. 이론적으로는 공격자가 이러한 소프트웨어의 알려진 취약점을 더 쉽게 악용할 수 있습니다.