01. 개요

HTTP(Hypertext Transfer Protocol)는 웹 클라이언트가 웹 서버에게 요청의 목적을 알리기 위해 Method라는 수단을 이용한다. Method는 목적에 따라 GET, POST, HEAD, PUT, DELETE, OPTIONS 등으로 분류되며 사전에 정의된 행위를 수행하게 된다. 이 중 PUT, DELETE Method의 경우 임의로 서버 내 파일의 생성 및 삭제가 가능하기 때문에 비인가 사용자에 의한 조작의 위험이 있어 사전예방 관점에서 취약점 존재여부를 진단하고 대응하게 된다.

[표 1] HTTP Method 설명

‘전자금융감독규정 취약점 분석•평가 기준(제2020-1호)’의 ‘웹/모바일/HTS 애플리케이션’ 진단 항목 에서는 HTTP Method으로 발생할 수 있는 보안위협에 대응하기 위해서 ‘WEB-SER-038, 불필요한 웹 메서드 허용’의 점검을 권고하고 있다. 해당 항목을 조치하기 위해서는 일반적으로 WEB/WAS에서 조치가 가능하기 때문에 당사에서는 WEB/WAS 진단 시에 해당 항목에 대한 진단기준을 별도로 두고 점검을 수행하고 있다.

[표 2] 전자금융감독규정 취약점 분석평가 기준 내 불필요한 웹 메서드 허용 항목

PUT, DELETE Method의 동작여부를 확인하기 위해서는 [그림 1]과 같이 OPTIONS Method를 통해 활성화 여부를 확인 후 [그림 2]와 같이 응답 값을 통해 공격 성공유무를 판단할 수 있게 된다.

[그림 1] OPTIONS Method 응답

PUT, DELETE Method의 기능이 성공적으로 수행된 경우에는 [그림 2]의 상위 결과와 같이 요청의 성공을 의미하는 상태코드 200을 응답할 것이고, 이러한 경우 취약으로 판단하게 된다. 반대로 상태코드가 403인 경우에는 공격이 실패하였기 때문에 양호로 판단할 수 있게 된다. 그러나 실제 공격을 수행하게 되는 경우 OPTIONS Method의 결과와 응답결과가 상이한 경우가 종종 발생되게 된다.

[그림 2] 허용된 Method 요청 시 상이한 응답 코드 (상 : 200 OK / 하 : 403 Forbidden)

이번 호에서는 [그림 2]의 하위 결과와 같이 OPTIONS Method의 결과와 실제 공격수행 결과가 상이하게 되는 경우의 원인과 결과에 대해서 좀더 자세하게 분석해보고자 한다.

02. 사전정보

OPTIONS Method의 응답결과에 따라 공격결과가 미치는 영향에 대해서 두 가지 가정을 설정하여 이를 각 항목의 조건 별로 분류하여 테스트를 진행하였다. 본격적인 테스트에 앞서 테스트 조건에 사용되는 REST API와 WAF에 대해서 간단하게 살펴보고 테스트를 진행하고자 한다.

1) REST(REpresentational State Transfer) API

REST는 웹의 장점을 최대로 활용할 수 있는 아키텍처 스타일로, 서버와 클라이언트 간 통신 방식 중 하나이다. 웹 사이트의 텍스트, 이미지 등 모든 자원에 대해 고유한 URI를 부여하고, HTTP Method를 통해 해당 자원에 대해 생성, 조회, 수정, 삭제 동작을 수행하는 등 제약조건의 집합이다. RESTful은 이러한 제약 조건(아키텍처 스타일, 아키텍처 원칙)을 모두 만족하는 것을 의미한다.

[표 3] REST API 규칙 예시

예를 들어, 요청 URI에 delete와 같이 행위(삭제)에 대한 표현이 나오면 REST 규칙을 만족한 것이 아니며, 삭제 기능은 DELETE Method를 통해 요청되어야 한다.

2) WAF(Web Application Firewall)

WAF는 웹 공격에 특화된 솔루션으로 OSI 7 Layer의 Application 계층에서 HTTP(80), 즉 웹 서비스로 시도되는 취약점 공격을 탐지 및 차단하는 기능을 한다. SQL Injection, XSS, 요청 Method 등에 대해 탐지 및 차단 기능을 포함한다.

[그림 3] WAF의 구성 아키텍처

03. 불필요한 웹 Method 허용 여부 테스트

앞서 세운 두 가지 가정을 테스트하기 위해 [그림 4]와 같이 환경을 구성하고 [표 4]와 같이 시스템 별로 PUT과 DELETE Method를 DENY 혹은 ALLOW로 설정하여, OPTIONS Method의 응답과 실제 동작 결과가 일치하지 않는 경우에 대해서 테스트를 진행하였다.

[그림 4] 불필요한 웹 Method 허용 여부 테스트 환경 구성도

[표 4] 케이스 별 DELETE Method DENY/ALLOW 여부

1) CASE 1

프레임워크와 웹 서버 단 설정의 차이가 존재할 경우, OPTIONS Method 응답과 실제 동작 결과가 일치하지 않을 것이라 예측하였다.

[그림 5] CASE 1 환경 구성 (프레임워크와 웹 서버 활성화)

[표 5] CASE 1 - DELETE Method DENY/ALLOW 여부

CASE 1와 관련된 설정파일 내용은 [그림 6]과 같다.

[그림 6] 설정파일 내용 (좌 : 프레임워크(FLASK) - DENY DELETE / 우 : 웹 서버(Apache) – ALLOW DELETE)

[그림 7] CASE 1 진행 프로세스 화면

2) CASE 2

[그림 8] CASE 2 환경 구성 (프레임워크와 웹 서버 활성화)

[표 6] CASE 2 - DELETE Method DENY/ALLOW 여부

CASE 2와 관련된 설정파일 내용은 [그림 9]와 같다.

[그림 9] 설정파일 내용 (좌 : 프레임워크(FLASK) - ALLOW DELETE / 우 : 웹 서버(Apache) – DENY DELETE)

[그림 10] CASE 2 진행 프로세스 화면

3) CASE 3

WAF 내 특정 Method에 대한 차단 정책이 존재할 경우, WAF에서 특정 요청에 대해 차단해 해당 요청이 프레임워크까지 도달하지 않아 OPTIONS Method 응답과 실제 동작 결과가 일치하지 않을 것이라 예측하였다.

[그림 11] CASE 3 환경 구성 (WAF와 프레임워크 활성화)

[표 7] CASE 3 Method 설정 값

CASE 3의 WAF 정책 내용은 [그림 12]와 같으며, 프레임워크 설정파일 내용은 [그림 9]의 좌측 화면과 같다.

[그림 12] 설정파일 내용 (WAF – DENY DELETE)

[그림 13] CASE 3 진행 프로세스 화면

OPTIONS Method 응답 내에 DELETE Method가 존재하는 것으로 서버 측에서 해당 Method를 ALLOW하고 있음을 확인하여, DELETE 요청을 보냈다. 그러나 응답으로 ‘200 OK’가 아닌 ‘403 Forbidden‘을 수신했고, OPTIONS Method 응답과 실제 동작 결과가 불일치함을 확인하였다.

4) CASE 4

CASE 3과 동일하게 WAF 내 특정 Method에 대한 차단 정책이 존재할 경우, WAF에서 특정 요청에 대해 차단해 해당 요청이 웹 서버까지 도달하지 않아 OPTIONS Method 응답과 실제 동작 결과가 일치하지 않을 것이라 예측하였다.

[그림 14] CASE 4 환경 구성 (WAF와 웹 서버 활성화)

[표 8] CASE 4 Method 설정 값

CASE 4의 WAF 정책 내용은 [그림 12] 와 같으며, 웹 서버 설정파일 내용은 [그림 6]의 우측 화면과 같다.

[그림 15] CASE 4 진행 프로세스 화면

CASE 3과 동일하게 OPTIONS 응답 내에 DELETE Method가 존재하는 것으로 서버 측에서 해당 Method를 ALLOW하고 있음을 확인하여, DELETE Method 요청을 보냈다. 그러나 응답으로 ‘200 OK’가 아닌 ‘403 Forbidden‘ 수신했고, OPTIONS Method 응답과 실제 동작 결과가 불일치함을 확인하였다.

04. 결론

OPTIONS Method 응답과 실제 동작 결과 일치 여부를 테스트해 본 결과는 [표 9]와 같다. CASE 1, 2의 경우는 OPTIONS Method 응답과 실제 동작 결과 일치했지만, 인프라를 구성하는 시스템에 특정 Method를 제한하는 정책을 가진 WAF가 있는 경우 결과가 불일치했다.

[표 9] 불필요한 웹 Method 허용 여부 테스트 결과

WAF는 OPTIONS Method 요청에 대해 ALLOW 되어있어 웹 서버로 OPTIONS 요청을 전달하게 된다. 웹 서버 설정은 DELETE와 OPTIONS 요청에 대해 모두 ALLOW 되어있으므로 ‘200 OK’와 함께 응답 헤더 항목 중 Allow에 허용된 Method를 담아 응답한다. 그러나 WAF에서 DELETE Method 요청에 대해 DENY 되어있으므로 DELETE 요청에 대해서는 ‘403 Forbidden’를 응답한다.

이와 같은 응답의 차이는 인프라 및 네트워크 구성 상에 적용되어 있는 보안장비와 그 인프라를 구성하고 있는 시스템에 상이한 보안 정책이 적용되어 있기 때문에 발생하며, 이를 통해 공격자가 네트워크 구성 등의 정보를 수집할 수 있도록 하기에 문제가 된다.

[그림 16] OPTIONS Method 응답과 실제 DELETE Method 동작 결과 간의 상관관계 구성도

05. 대응방안

1) 일관된 보안 정책 반영

인프라 및 네트워크 구성상에 적용되어 있는 보안장비와 그 인프라를 구성하고 있는 시스템에 대해 일관된 보안 정책을 반영해야 한다. 앞서 설명한 바와 같이 보안정책이 비일관적으로 반영되어 있을 경우 그를 통해 공격자가 네트워크 구성 등의 정보를 수집할 수 있기에 문제가 되며, 일관된 보안정책을 반영함으로써 공격의 위험을 줄일 뿐 아니라 각 시스템 별로 통제력을 개선할 수 있다.

[표 10] 일관/비일관 보안 정책 반영 예

2) 리소스 별 Method 제한

리소스 별 적절한 요청 Method를 지정하여 Method가 리소스에 부합하지 않는 경우 오류 상태코드로 응답해야 한다. Apache의 경우 httpd.conf 설정파일 내 를 통해 서비스 운영상 필요한 Method를 기재하거나 를 통해 제한할 Method를 기재하여 제한할 수 있다. [그림 17]은 를 통해 전체 디렉터리에서 GET, POST Method을 제외한 모든 Method에 대한 접근을 거부하는 설정이며, 디렉터리 경로를 변경함으로써 불가피하게 DELETE, PUT Method에 대해 허용해야 하는 경우에 대해 리소스 별로 관리할 수 있다.

[그림 17] Apache 불필요한 웹 Method 제한 설명 (좌 : LimitExcept 지시자 이용 / 우 : Limit 지시자 이용)

3) 사용자 권한 검증

앞서 설명한 바와 같이 REST API 적용 등의 이유로 DELETE, PUT Method 차단이 불가능한 경우 사용자 별로 권한을 부여해 특정 권한을 가진 인가된 사용자의 Method 요청에 대해서만 응답해야 한다. 표준인증방식을 통해 사용자 별로 권한을 부여하여 관리할 수 있으며, 권한을 통해 관리할 경우 [표 11]의 보안 원칙을 준수하여야 한다.

[표 11] 권한 검증 시 보안 원칙

06. 참고자료

[1] REST API 소스 (python)

   - https://github.com/kiteco/kite-python-blog-post-code/tree/master/flask-tutorial/restful-apis-with-flask 

[2] REST API 개념 설명

   - https://meetup.toast.com/posts/92 

   - https://jeong-pro.tistory.com/180

[3] WAF(Web Application Firewall)란?

   - https://ipwithease.com/introduction-to-waf-web-application-firewall/

[4] HTTP Request Method 설명

   - https://developer.mozilla.org/ko/docs/Web/HTTP/Methods

[5] API 보안 점검

   - https://github.com/shieldfy/API-Security-Checklist/blob/master/README-ko.md

   - https://restfulapi.net/security-essentials/