27. WAF 우회 플레이북: 시그니처를 흔드는 작은 변형

WAF 테스트의 목적은 차단 문자열을 찾아내는 데 있지 않다. 프록시, 웹 서버, 프레임워크가 같은 요청을 같은 의미로 해석하는지 확인하고, 정상 사용자의 요청까지 망가뜨리지 않는 규칙을 만드는 데 있다. 아래 절차는 사전 승인된 랩·CTF·자기 소유 시스템에서만 수행한다.

시그니처보다 해석 파이프라인을 그린다

먼저 원시 요청이 어디에서 URL 디코딩, 대소문자 변환, 본문 파싱, 유니코드 정규화를 거치는지 기록한다. WAF가 차단한 표현과 백엔드가 실제로 받은 표현을 별도 로그로 비교한다. 이 비교 없이 이중 인코딩이나 주석 삽입을 무작정 시도하면 취약점을 찾는 것이 아니라 관측 가능성을 잃게 된다.

변형은 한 번에 한 차원만 바꾼다. 공백·대소문자·인코딩·JSON 표현을 각각 독립적으로 바꾸고, 상태 코드·응답 길이·백엔드 로그를 기준선과 비교한다. 차이가 생겨도 그것이 보안 우회인지 단순한 파서 오류인지 구분한다. 특히 WAF와 앱이 서로 다른 디코딩 횟수를 갖는다면, 룰을 더 복잡하게 만드는 대신 공통 canonicalization을 먼저 해결해야 한다.

기능 보존과 안전한 검증

SQLi나 XSS 같은 공격 문자열 대신 랩의 무해한 탐지 토큰을 사용하고, 요청률과 데이터 범위를 제한한다. 헤더 변형은 실제 프록시가 신뢰하는 헤더 목록을 확인하는 용도로만 사용한다. X-Forwarded-For나 X-Original-URL을 외부 입력으로 신뢰하는지 확인할 때는 접근 로그와 라우팅 결과를 대조하고, 관리자 경로 접근이나 외부 전송을 시도하지 않는다.

방어의 성공 조건

룰의 품질은 공격 하나를 막았는지가 아니라 동일 의미의 표현을 일관되게 처리하고 정상 트래픽의 오탐률을 관리하는지로 평가한다. 앱이 파싱한 구조화된 값에 대해 타입·길이·허용 값 검사를 수행하고, WAF는 속도·세션·비정상 패턴을 보조적으로 본다. 룰 변경 뒤에는 정상 회귀 테스트, 로그 상관관계, 차단 사유의 설명 가능성을 함께 검증한다.

우회는 게임의 끝이 아니라 경계가 두 개였다는 증거다. 어느 계층에서 의미가 달라졌는지를 찾아 하나의 해석 계약으로 줄이는 것이 재현 가능한 개선이다.