◼ 요청 바디 접근
: 기본적으로 ModSecurity는 요청 바디 내용에 대해 접근, 처리, 분석을 하지 않는다. 요청 바디에 대한 정확석을 높이기 위해서는 모드시큐리티에 대해 몇 개의 지시자를 설정해야한다.
1) SecRequestBodyAccess가 ON으로 설정돼 있으면 ModSecurity가 요청 바디 내용을 버퍼에 보관하고 REQUEST_BODY 변수 및 ARGS 컬렉션 데이터의 내용을 채운다.
2) SecRequestBodyLimit는 요청 바디가 가질 수 있는 크기의 임계치를 설정한다. 만약 임계치보다 수치가 큰 요청이 들어오게 되면 413 HTTP 응답 상태 코드를 리턴한다. (요청 속성이 너무 클 경우)
3) SecRequestBodyNoFilesLimit는 위에 있는 SecRequestBodyLimit와 유사하지만 파일 첨부를 제외한 수치다.
4) SecRequestBodyInMemoryLimit는 메모리에 버퍼링할 크기를 지정한다. 이 설정보다 데이터가 큰 경우에는 디스크의 임시 파일로 저장된다.
5) SecRequestBodyLimitAction은 요청 바디가 임계치보다 큰 경우 어떤 행위를 취할지 결정한다. 거절 또는 부분적 처리 옵션을 선택할 수 있다. (거절: 413 응답코드 불러오고, 부분적 처리: 요청 진행.)
◼ 잘못된 요청 바디 식별
: ModSecurity가 요청 바디의 내용을 파싱하려고 할 때 문제가 발생할 경우에 다양한 오류를 생성하게 된다. 공격자는 의도적으로 페이로드를 조작해 보안 검사를 회피하려고 시도하는데, 이와 동시에 웹 어플리케이션에 대해 의도된 공격을 실행하므로 식별하는 기능이 필수적이다.
! 요청 바디 처리에 실패하는 경우 요청 거절(차단모드 배포)와 높은 심각도의 경고 로깅(탐지 모드 배포) !
◼ 다중 인코딩 사용을 식별
: 공격자는 주로 공격 페이로드를 여러 번 인코딩하여 사용한다. 보안 분석 과정에서 한 번의 디코딩 후 검사하도록 적용했다면 공격 페이로드는 탐지를 회피할 것이다.
EX1) XSS 페이로드
: 전형적인 자바스크립트 경고 메시지를 발생시킨다. <script 문자열 검사를 하는 시그니처를 통해 쉽게 식별된다.
두 번째 XSS 페이로드에서 <, >, / 문자는 URL 인코딩돼 있다. 그러나 대부분의 보안 필터는 디코딩 함수를 적용해 이와 같은 페이로드를 식별할 수 있다. 하지만 공격자가 두번 인코딩을 할 경우에는, 보안 필터에 한번의 디코딩 루틴이 포함돼 있다면 <script 부분과 일치하지 않을 것이다. 중첩돼 있는 인코딩도 정규화될 수 있도록 반복적으로 수행해야, 인코딩의 비정상적인 사용을 탐지할 수 있다.
출처: ModSecurity를 활용한 웹 애플리케이션 방어레시피_라이언 바넷 지음
'Network' 카테고리의 다른 글
[1] 네트워크 계층의 헤더 기능 (0) | 2021.03.27 |
---|---|
ModSecurity 6장_응답 데이터 분석 (0) | 2021.03.07 |
ModSecurity 4장_평판 및 서드파티 연관성 (0) | 2021.02.27 |
ModSecurity 3장_독을 품은 폰(해커 트랩) (0) | 2021.02.27 |
ModSecurity 2장_취약점 확인 및 개선 (0) | 2021.02.17 |