CBBH - Web Attacks[Intro to HTTP Verb Tampering]

Verb HTTP 프로토콜은 HTTP 요청의 시작 부분에서 다양한 HTTP Method를 허용하며 작동한다. 웹 서버 구성에 따라 웹 애플리케이션은 다양한 기능에 대한 특정 HTTP 메서드를 수락하고 요청 유형에 따라 특정 작업을 수행하도록 스크립팅될 수 있다.

가장 일반적으로 사용되는 두 가지 Method인 GET, POST를 가장 많이 고려하지만, 모든 클라이언트는 HTTP 요청에서 다른 Method를 보낸 다음 웹 서버가 이러한 메서드를 어떻게 처리하는 지 볼 수 있다.

웹 애플리케이션과 백엔드 웹 서버가 모드 GET 및 POST 요청만 허용하도록 구성되어 있다고 가정한다. 이 경우 다른 요청을 보내면 웹 서버 오류 페이지가 표시되어 이는 그 자체로는 큰 취약점이 아니다.

반면에 웹 서버 구성이 웹 서버에서 요구하는 HTTP Method만 허용하도록 제한되지 않고, 웹 애플리케이션이 다른 유형의 HTTP 요청을 처리하도록 개발되지 않는 경우, 이 안전하지 않은 구성을 악용해 접근할 수 없는 기능에 접근하거나 특정 보안 제어를 우회할 수 있다.

---

HTTP Verb Tampering

이 공격을 이해하려면 HTTP 프로토콜에 허용되는 다양한 Method에 대해 알아야 한다. HTTP에는 웹 서버에서 HTTP Method로 허용할 수 있는 방법이 9개가 있다. GET과 POST를 제외하고 사용되는 HTTP Verb는 다음과 같다. https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

HTTP request methods - HTTP | MDN

 

• HEAD : GET 요청과 동일하지만 응답에는 headers만 존재하고 내용은 없다.
• PUT : 요청한 페이로드를 지정된 위치에 저장한다.
• DELETE : 지정된 위치의 리소스를 삭제한다.
• OPTIONS : 웹 서버가 허용하는 다양한 옵션(예: 지원하는 Method)을 보여준다.
• PATCH : 지정된 위치의 리소스에 부분적인 수정 사항을 적용한다.
• CONNECT : 대상 리소스로 식별된 서버에 터널을 설정한다.
• TRACE : 대상 리소스 경로를 따라 메시지 루프백 테스트를 수행한다.

위의 방법 중 일부는 백엔드 서버의 웹 디렉터리에 파일을 쓰거나 삭제하는 것과 같이 민감한 기능을 수행할 수 있다. 웹 서버가 이러한 방법을 관리하도록 안전하게 구성되지 않은 경우, 이를 사용해 백엔드 서버를 제어할 수 있다.

그러나 HTTP Verb Tampering 공격을 더 흔하게 만드는 것은 백엔드 웹 서버나 웹 애플리케이션의 잘못된 구성으로 인해 발생하며, 둘 다 취약점을 트리거할 수 있다.

Insecure Configurations

안전하지 않은 웹 서버 구성은 HTTP Verb Tampering 취약점을 발생시킨다. 웹 서버의 인증 구성은 특정 HTTP 메서드로 제한될 수 있으며, 이는 일부 HTTP 메서드가 인증 없이도 접근할 수 있도록 한다.예를 들어, 시스템 관리자는 다음 구성을 통해 특정 웹 페이지에서 인증을 요구할 수 있다.

<Limit GET POST>
    Require valid-user
</Limit>

위에서 볼 수 있듯, 구성이 인증 방법에 대한 요청 GET과 POST 요청을 모두 지정하더라도 공격자는 다른 HTTP Method(예: HEAD)를 사용해 이 인증 메커니즘을 완전히 우회할 수 있다. 이는 인증 우회로 이어지고 공격자는 접근할 수 없는 웹 페이지와 도메인에 접근할 수 있다.

Insecure Coding

보안이 취약한 코딩 방식은 또 다른 유형의 HTTP Verb Tampering 취약점을 유발할 수 있다. 다만 일부는 이를 Verb Tampering으로 간주하지 않을 수도 있다.

이러한 취약점은 웹 개발자가 특정 취약점을 완화하기 위해 특정 필터를 적용하지만, 해당 필터가 모든 HTTP 메서드를 고려하지 않을 경우 발생할 수 있다.

예를 들어, 웹 페이지가 SQL Injection 취약점에 노출되었고, 백엔드 개발자가 이를 완화하기 위해 입력값 검증 필터를 적용했다고 가정한다.

$pattern = "/^[A-Za-z\\s]+$/";

if(preg_match($pattern, $_GET["code"])) {
    $query = "Select * from ports where port_code like '%" . $_REQUEST["code"] . "%'";
    ...SNIP...
}

위 코드에서 볼 수 있듯이, 입력 검증 필터는 GET 요청의 code 파라미터에 대해서만 적용되고 있다. 즉, GET 요청에서 악성 문자가 포함되지 않았다면, 해당 쿼리는 실행된다.

그러나 쿼리를 실행할 때는 $_REQUEST[”code”] 값을 사용하고 있으며, 이 변수는 POST 파라미터도 포함될 수 있다.

결과적으로, GET 요청이 아닌 POST 요청을 사용하면 필터를 우회해 SQL Injection을 수행할 수 있다. 이 경우, GET 파라미터는 비어있기 때문에 보안 필터를 통과하게 되며, 결국 SQL Injection 취약점이 발생하게 된다.