[웹 방어 레시피] 5장, 요청 데이터 분석

 

요청 데이터 수집

인바운드 요청 데이터에 대해 보안 분석을 하기 전에 모든 데이터 요소에 제대로 접근할 수 있는지 확인해야 한다. 웹 서버의 기본 로깅 설정인 공통 로그 포맷(Common Log Format)으로 캡처된 제한된 데이터를 떠올릴 것이다. 어떠한 잠재적인 공격 경로를 놓치지 않으려면 모든 요청 데이터에 적절한 가시성을 가지고 있는지 확인해야 한다. 예를 들어 모든 요청 헤더 데이터 또는 요청 바디에 접근할 수 없다면 공격을 놓칠 수도 있다.

 

'오류 발생 시 개방(Falt Open)'이라는 개념은 시스템이 오류가 발생하는 경우 데이터의 전달을 허용하는 것으로 심각한 보안 문제다.

 

레시피 5-1, 요청 바디 접근

이 레시피는 다양한 유형의 요청 바디(Request body) 콘텐츠에 접근할 수 있도록 ModSecurity를 구성하는 방법을 보여준다.

 

기본 지시자

기본적으로 ModSecurty는 요청 바디 내용에 대해 접근, 처리, 분석을 하지 않는다. 공격자는 POST 바디 매개변수로 탐지를 쉽게 회피할 수 있기 때문에 미탐(false negative)과 관련한 심각한 문제가 있다.

 

■ SecRequestBodyAccess : 만약 ON으로 설정돼 있으면 ModSecurity가 요청 바디 내용을 비퍼에 보관하고 REQUEST_BODY 변수 및 ARGS 컬렉션 데이터의 내용을 채운다.

 

■ SecRequestBodyLimit : 요청 바디가 가질 수 있는 크기의 임계치를 설정한다. 이 설정은 파일 첨부를 포함한 수치다. 만약 임게치보다 큰 요청이 오게 되면 413(요청 속성이 너무 큼) HTTP 응답 상태 코드를 리턴한다.

 

■ SecRequestBodyNoFilesLimit : 메모리에 버퍼링할 크기를 지정한다. 이 설정보다 데이터가 큰 경우에는 디스크의 임시 파일로 저장된다.

 

■ SecRequestBodyLimitAction : 요청 바디가 임계치보다 큰 경우 어떤 행위를 취할지 결정한다. 거절 또는 부분적 처리 옵션을 선택할 수 있다. 거절을 선택한 경우 앞에서 언급한 것처럼 413 HTTP 응답 상태 코드를 트리거하며, 부분적 처리를 선택한 경우 요청을 진행한다. 그러나 임계치에 설정된 부분까지만 요청 바디를 검사한다. 이는 보안 관점에서 적합하지 않지만 보안 설정의 초기 배포 단계에서 예기피 않은 차단을 방지하는 데 도움을 준다.

 

XML/SOAT 콘텐츠 접근

기본적으로 ModSecurity는 두 개의 중요한 요청 바디 콘텐츠 유형에 대해 접근 및 처리하는 방법을 알고 있다

• application/x-www-form-urlencoded : 매개변수 데이터를 요청 바디 내에 전달하는 가장 일반적인 콘텐츠 유형이다.
• multipart/form-data : 별도의 파일을 전송하는 것처럼 다량의 바이너리 데이터를 전달하는 경우 가장 일반적인 콘텐츠 유형이다.

레시피 5-2, 발못된 요청 바디 식별

이 레시피는 요청 바디가 잘못된 경우 ModSecurity에서 오류를 생성하는 것을 보여준다.

 

ModSecurity가 요청 바디 콘텐츠를 피싱하려고 할 때 문제가 발생하면 다양한 오류를 생성한다. 공격자는 종종 의도적으로 페이로드를 조작해 보안 검사를 회피하려고 시도하지만, 여전히 대상 웹 애플리케이션에 대해 의도된 공격을 실행하므로 이 기능은 필수적이다.

 

[주의] 임피던스 불일치 : 외부의 보안 규칙 집행 계층으로 웹 애플리케이션을 보호한는 것은 명백한 이점이 있지만, 이는 구조적으로 하나의 중요한 문제를 노출한다. 각 웹 애플리케이션 기술(ASP, NET, PHP, 자바)은 HTTP 트랜잭션 데이터를 분석, 피싱, 추출, 해석하는 방법이 다르며 종종 예기치 못한 방법으로 이뤄진다. 이는 보안 계층 분석이 보호되는 웹 애플리케이션과 일치하지 않는 경우 미탐 회피 시나리오를 야기할 수 있다.

 

멀티파트 폼 데이터 오류

멀티파트(multipart) 폼 데이터 요청도 다양한 잠재적 회피 방법을 가지고 있다. 대부분은 요청 파일명 메타데이터와 실제 콘텐츠를 파싱하는 데 집중돼 있다.

 

이와 같은 유형의 유효성 검사는 애플리케이션이 트랜잭션을 처리하는 것을 방지하고 잠재적으로 보안 문제가 발생하는 것도 방지할 수 있다.

 

데이터 인코딩 서버

HTTP 트랜잭션에서 콘텐츠 인코딩은 다양한 합법적인 용도로 사용되지만 공격자는 그들의 악성 페이로드를 숨기기 위해 인코딩을 활용한다. 이러한 인코딩을 인식하고 적절하게 디코딩하며 악성으로 분류하는 것은 필수다.

 

레시피 5-3, 유니코드 정규화

이 레시피는 트랜잭션 데이터를 디코딩하는 경우 어떻게 유니코드 포인트를 지정할 수 있는지 보여준다.

 

가장 적합한 매핑

예상치 못한 캐릭터 세트로 인코딩된 유니코드를 애플리케이션에서 어떻게 처리해야 하는가? 이는 애플리케이션이 내부적으로 시각적 측면에서 유사해 보이는 캐릭터 코드와 문자를 매핑하는 '가장 적합한 매핑'의 문제를 제기한다.

 

문제는 이와 같은 인바운드 페이로드가 대부분의 XSS 정규 표현식 페이로드와 일치하지 않는 것이다. 그러나 애플리케리션 자체에서 실행 가능한 코드로 변경할 것이다.

 

ModSecurity의 유니코드 매핑

이와 같은 유형의 유니코드 회피를 방지하기 위해 유니코드 매핑 파일을 포함하고 적절한 코드 포인트 선언을 지정해 ModSecurity가 웹 애플리케이션에서 어떻게 페이로드를 정규화하는지 알 수 있도록 해야 한다. ModSecurity 압축 파일은 다양한 코드 포인트에 따라 특정 문자를 매핑할 수 있도록 unicode.mapping 파일을 포함하고 있다.

 

유니코드 매핑을 사용하기 위해 두 개의 지시자가 설정돼 있어야 한다.

• SecUnicodeMapFile : ModSecurity에게 컨템츠를 매핑하기 위해 어떤 파일을 사용해야 하는지 알려준다.
• SecUnicodeCodePage : ModSecurity에게 사이트에서 어떤 코드 포인트가 사용되고 있는지와 유니코드 데이터를 어떤 설정으로 정규화해야 하는지 알려준다.

전각/반각 유니코드 문자 사용 탐지

반각 문자를 사용해 공격자는 '임피던스 불일치' 경고 부분에서 설명한 것처럼 필터를 회피할 수 있다.

 

이 규칙은 REQUEST_URI와 REQUEST_BODY 변수 내에 이런 식으로 인코딩된 문자가 있을 경우 경고를 발생시킨다.

 

레시피 5-4, 다중 인코딩 사용을 식별

이 레시피는 다중 인코딩 사용 시 식별하는 방법을 보여준다.

 

공격자가 주로 사용하는 방법은 공격 페이로드를 여러 번 인코딩하는 것이다. 보안 분석 과정에서 한 번의 디코딩 후 검사하도록 적용했다면 공격 페이로드는 탐지를 회피할 것이다. 

 

레시피 5-5, 비정상적인 인코딩 식별

이 레시피는 사용 중인 URL 인코딩을 검증하는 방법을 보여준다.

 

RFC 2396, '통합 자원 식별자 : 일반 문법'은 URI 데이터의 16진수 인코딩에서 사용되는 형식을 설명한다.

 

요청 내 16진수로 인코딩된 페이로드를 검증하기 위해 다음과 같이 OWASP ModSecurity CRS의 modsecurity_crs_20_protocol_violations.conf 파일을 사용할 수 있다.

 

비정상적인 입력 값 검증

요청 데이터의 형식 및 구조에 이상이 있는 경우 식별하는 방법에 초점을 맞춘다. 

 

레시피 5-6, 비정상적인 요청 메소드 식별

이 레시피는 자원에 대해 비정상적인 HTTP 요청 메소드가 사용된 경우 식별하는 방법을 보여준다.

 

전역적인 요청 메소드 허용 목록

HTTP 요청 데이터의 첫 번째 검사 항목은 요청 메소드다. OWASP ModSecurity CRS는 관리자가 전체 사이트에 대해 어떤 HTTP 요청 메소드를 허용할지 modsecurity_crs_10_condif.conf 파일 내에 정의할 수 있도록 한다.

 

SecAction 규칙은 허용된 HTTP 요청 메소드의 목록을 나열할 수 있도록 트랜잭션 변수 값을 설정한다. 이 데이터는 modsecurity_crs_30_http_policy.conf 파일 내의 규칙 내에서 매크로 확장 점사 시 사용한다. 이는 변수 목록에 정의된 데이터와 현재의 요청 메소드를 검사한다.

 

이러한 유형의 검사는 공격자가 애플리케이션 내 어디에서나 허용되지 않은 요청 메소드를 사용할 경우 식별하는 데 도움이 된다. 이러한 접근 방법은 공격자가 전역적으로 허용된 다른 요청 메소드를 사용하지만 특정 자원에 대해 사용할 경우 보안 문제를 야기할 수 있다는 제한이 있다. 비정상적인 요청 메소드를 식별하는 것은 접근 제어 제한을 우회하려는 시도를 식별하는 데 도움이 된다. 이러한 비정상점은 크로스 사이트 요청 위조 같은 공격을 의미할 수 있다. 따라서 자원당 예상되는 내용의 학습된 프로파일을 개발하는 것이 중요하다.

 

레시피 5-7, 잘못된 URI 데이터 검출

이 레시피는 잘못된 URI 데이터 사용을 확인하는 방법을 보여준다.

 

HTTP RFC 2616은 옵션 구성 요소가 있는 HTTP 스키마의 적절한 형식을 정의하고 있다.

 

이 정보를 바탕으로 인바운드 HTTP 요청에 대해 컴플라이언스를 적용할 수 있다. OWASP ModSecurity CRS는 modsecurity_crs_20_protocol_violations.conf 파일 내에 다음과 같은 규칙을 포함한다.

 

레시피 5-8, 비정상적인 요청 헤더 탐지

이 레시피는 비정상적인 요청 헤더를 식별하는 다양한 방법을 보여준다.

 

누락된 요청 헤더

일반적인 웹 브라우저는 다음과 같은 요청 헤더를 전송한다.

• 호스트
• 사용자 에이전트
• 수락

공격자가 자동화된 공격 스크립트 또는 프로그램을 만들 때는 종종 이러한 표준 웹 브라우저 헤더를 포함하지 않는다. OWASP ModSecurity CRS는 modsecurity_crs_21_protocol_anomalies.conf 파일에 이러한 헤더들에 대해 검사하는 부분을 포함한다.

 

비정상적인 헤더 내용

숨길 수 없는 특징 표식은 요청 헤더에 특정 데이터가 있다는 것만으로 해당 요청이 의심스럽다는 것을 의미한다.

 

비정상적인 헤더 순서

실제 웹 브라우저는 각 브라우저에 따라 고유의 요청 헤더 순서를 가지고 있다. p0f라는 툴은 실제 네트워크 트래픽을 모니터링하고 소스 트래픽의 다양한 면을 분석해 사용 중인 OS와 다른 흥미로운 정보를 식별한다. p0f의 버전3는 애플리케이션 핑거프린팅 기능을 포함하고 있다. 이는 최근 주로 사용되고 있는 웹 브라우저의 요청 헤더 순서 정보를 포함하고 있다.

 

 이 웹 브라우저들의 헤더 순서를 비교할 때 하나의 차이점은 구글 크롬의 경우 호스트 헤더를 처음에 나열하는 반면, 마이크래프트 인터넷 익스플로러는 그렇지 않다는 것이다. 요약하면, 페이로드와 상관없이 간단히 클라이언트가 전송하는 요청 헤더의 순서를 보고 적합 여부를 결정할 수 ㅇㅆ다.

 

요청 헤더의 순서를 기억하라. Accept, Accept-Language, Referer, User-Agent, If-Modified-Since, Host인 것을 기억하라. 이 순서는 HOIC 공격 트래픽의 핑거프린트로 사용할 수 있다.

 

레시피 5-9, 추가 배개변수 탐지

이 레시피는 요청에 예기치 않은 매개변수가 추가됐을 때 식별하는 방법을 보여준다.

 

루아 스크립트는 매개변수가 너무 많다는 것을 알려주고 올바르지 않은 매개변수의 이름을 지정하는 두 개의 변수를 만들었다.

 

레시피 5-10, 누락된 매개변수 탐지

이 레시피는 현재 요청에서 필요한 매개변수가 누락됐을 경우 알 수 있는 방법을 보여준다.

 

루아 스크립트는 현재 매개변수의 개수가 학습된 프로파일의 최소 개수보다 적다는 것을 저장하는 변수를 생성했다.

 

레시피 5-11, 중복된 매개변수명 탐지

이 레시피는 공격자가 중복된 이름으로 매개변수를 삽입하려고 시도할 때 탐지하는 방법을 보여준다.

 

HTTP 매개변수 오염에 대해서는 레시피 5-2에서 논의했다. 기본적인 개념은 동일한 이름을 가진 여러 개의 페이로드를 처리하는 방식이 웹 애플리케이션마다 다양하다는 것이다. 여기서는 SQL 인젝션 공격에서 HPP가 네거티브 보안 필터를 우회하기 위해 어떻게 사용되는지 예시를 보여준다.

 

OWASP ModSecurity CRS의 SQL 인젝션 시그니처는 이와 같은 페이로드를 쉽게 캡처한다. 따라서 공격자는 HPP를 활용해 페이로드를 after라고 명명된 세 개의 매개변수를 사용함으로써 세 부분으로 나눈다.

 

규칙은 각 페이로드에 개별적으로 적용되므로 SQL 인젝션 공격 페이로드를 분할해 시그니처를 회피했다. 요청이 백엔드 ASP 웹 애플리케이션에 도착해서야 문법적으로 올바른 공격 페이로드로 재조립된다.

 

이 규칙 집합은 어떠한 매개변수명이라도 중복되면 경고를 발생시킨다. 또한 연결된 HPP 페이로드를 저장하는 새로운 트랜잭션 변수도 만든다. 이 변수 또한 다른 규칙에 의해 평가될 수 있다.

 

레시피 5-12, 비정상적인 매개변수 페이로드 크기 탐지

이 레시피는 필수 매개변수의 크기가 너무 작서나 너무 큰 경우 알아낼 수 있는 방법을 보여준다.

 

루아 스크립트는 username과 password 매개변수의 길이가 학습된 프로파일과 일치하지 않음을 나타내는 여러 변수를 생성했다. 이 변수들은 다음 규칙에서 평가된다.

 

레시피 5-13, 비정상적인 매개변수 문자 클래스 탐지

이 레시피는 공격자가 예상치 못한 문자를 매개변수 페이로드에 사용할 때 식별하는 방법을 보여준다.

 

루아 스크립트는 username 매개변수 페이로드가 학습된 프로파일과 일치하지 않는다는 것을 나타내는 변수를 생성했다. 이 변수는 다음 규칙에서 평가된다.

 

 

---

출처: ModSecurity를 활용한 웹 애플리케이션 방어 레시피, 라이언 바넷 지음