WAF 입문: 코드 수정 전 노출을 줄이는 규칙

한 문장으로 이해하기

Cloudflare가 공개한 취약점 발견·조치 절차에서 WAF(Web Application Firewall, 웹 애플리케이션 방화벽) 규칙은 취약한 코드에 도달하는 특정 요청의 노출을 줄이는 통제 수단으로 사용됩니다. 코드 수정이 검토되고 배포되는 동안 그 요청을 앞단에서 막는 역할입니다. 이 강좌를 마치면 세 가지를 할 수 있습니다. 첫째, WAF 규칙이 무엇을 겨냥하는지 자기 말로 설명하기. 둘째, Cloudflare 절차에서 규칙이 제안되고 검증되는 단계를 순서대로 말하기. 셋째, 규칙을 제안할 수 있는 조건과 그 한계를 구분하기. 사전지식은 거의 필요 없습니다. 웹 요청에는 경로와 방식 같은 세부 정보가 담길 수 있다는 정도만 알면 충분합니다.

왜 필요한가

Cloudflare는 대형 언어 모델이 코드베이스(서비스를 이루는 소스 코드 전체)의 약점을 빠르게 드러내면서 발견 건수가 늘 수 있다고 설명합니다. 같은 기술을 공격자도 쓸 수 있어, 취약점 발견과 악용의 일부가 빨라질 수 있다고도 밝힙니다. 발견은 빨라지는데 고치는 일에는 검토와 배포 시간이 듭니다.

Google은 방어 측의 이점이 결함을 발견한 시점과 고치는 시점 사이의 시간을 줄이는 데서 나온다고 설명합니다. WAF 규칙은 바로 그 사이의 시간을 다루는 수단입니다. 코드가 아직 그대로여도, 그 코드에 닿는 요청을 앞단에서 막아 노출을 줄일 수 있기 때문입니다.

어떻게 이루어지는가

아래 단계는 WAF 일반의 보편적 작동 원리가 아니라, Cloudflare가 공개한 취약점 발견·조치 절차의 흐름입니다.

1. 운영 데이터를 확인합니다. 어떤 경로가 실제로 살아 있는지, 요청량은 얼마나 되는지, 최근 보안 이벤트가 있었는지, 이미 적용된 WAF 규칙이 있는지를 함께 봅니다.
2. 소스 코드(프로그램을 구성하는 코드)를 분석해 약점 후보를 찾습니다. 다만 코드 분석만으로는 그 코드에 연결되는 운영 경로, 요청량, 의심스러운 요청, 이미 걸려 있는 보호 조치를 알 수 없습니다.
3. 코드에서 나온 발견을 운영 데이터와 연결합니다. 요청량이 많은 경로는 더 엄격하게 살핍니다.
4. 위험도를 정합니다. 코드 증거를 바탕으로 초기 위험도를 매긴 뒤, 트래픽이 많거나 누군가 그 지점을 살펴본 정황이 있으면 위험도를 올립니다.
5. 조치를 제안합니다. 근거가 충분하면 코드 수정안과 함께, 취약한 코드에 도달하는 요청의 방식·경로 등으로 범위를 좁힌 WAF 사용자 규칙을 제안합니다.
6. 제안을 검증합니다. 규칙의 문법을 확인하고, 실제 고객 요청이 아니라 예상 요청을 본뜬 시험 자료로 시험합니다. 검사가 실패하거나 결과가 모호하면 그 제안은 고객 검토 전에 보류됩니다.

검증을 통과해도 고객 환경이 저절로 바뀌지는 않습니다. 고객이 결과를 검토한 뒤 시험할지 배포할지 스스로 결정합니다.

하나의 예시로 따라가기

다음은 이해를 돕기 위한 가상 예시이며, 실제 사건이나 출처에 나온 사례가 아닙니다. 작은 온라인 서점이 있고, 주문을 처리하는 경로의 코드에 결함 후보가 발견됐다고 해봅시다.

코드 분석만으로는 이 결함이 얼마나 급한지 알 수 없습니다. 그래서 운영 데이터를 함께 봅니다. 이 주문 경로는 살아 있고, 요청량이 많으며, 이미 걸려 있는 보호 조치는 없습니다. 그러면 초기 위험도는 트래픽을 근거로 더 높게 조정됩니다.

이제 조치가 제안됩니다. 하나는 코드 수정안이고, 다른 하나는 그 결함에 도달하는 요청의 방식과 경로로 범위를 좁힌 WAF 규칙입니다. 규칙은 문법 검사와 예상 요청을 본뜬 시험 자료로 시험을 거칩니다. 검사가 실패하면 이 제안은 서점 담당자에게 오지도 않습니다.

검증을 통과하면 담당자가 검토하고 시험이나 배포를 결정합니다. 규칙이 적용되더라도 목적은 제안된 범위와 일치하는 요청의 노출을 줄이는 것입니다. 결함을 없애는 것은 여전히 코드 수정안의 몫이고, 서점 개발 팀은 그 시간 동안 수정안을 검토해 배포합니다.

언제 쓰고 언제 쓰지 않는가

첫째, 막을 요청을 근거로 특정할 수 있어야 합니다. Cloudflare는 경로 패턴이 변수와 와일드카드(어떤 값이든 대신하는 기호)로만 이루어져 있으면 근거 있는 범위 설정이 어렵기 때문에 규칙을 제안하지 않는다고 설명합니다. 무엇을 겨냥할지 뚜렷하지 않으면 규칙이 만들어지지 않습니다.

둘째, 규칙과 코드 수정은 서로 다른 조치입니다. 제안된 WAF 규칙은 코드 수정이 검토되고 배포되는 동안의 노출을 줄이는 역할이고, 결함을 고치는 조치는 코드 수정안으로 따로 제안됩니다. 둘을 바꿔 쓸 수 없습니다.

셋째, 범위를 좁게 잡고 검증과 사람의 검토를 거쳐야 합니다. 규칙은 취약한 코드에 도달하는 데 필요한 요청 세부 정보를 중심으로 좁게 설정되고, 문법 검사와 시험 자료 검사를 통과해야 하며, 그 뒤에도 고객이 검토해 결정합니다. 검사가 실패하거나 결과가 모호하면 제안은 고객 검토 전에 보류됩니다.

핵심 정리와 확인문제

Cloudflare 사례에서 WAF 규칙은 취약한 코드에 닿는 특정 요청을 앞단에서 막아 코드 수정 전까지의 노출을 줄이는 통제 수단입니다. 결함 자체는 코드 수정으로 없앱니다. 그리고 무엇을 막을지 근거로 특정할 수 있을 때만 규칙이 제안됩니다.

1. Cloudflare 절차에서 제안되는 WAF 규칙의 목적은 무엇인가요?
2. Cloudflare 절차에서 WAF 규칙이 만들어져 실제로 적용되기까지의 주요 단계를 순서대로 설명해 보세요.
3. 경로 패턴이 변수와 와일드카드로만 이루어져 있을 때 규칙을 제안하지 않는 이유는 무엇인가요?

1번 정답: 취약한 코드에 도달하는 요청의 방식·경로 등으로 범위를 좁혀, 코드 수정 전까지의 노출을 줄이는 것입니다. 해설: 이는 WAF 일반의 보편 원리가 아니라 Cloudflare가 공개한 절차에서의 역할입니다.

2번 정답: 운영 데이터 확인, 소스 코드 분석, 코드 발견과 운영 데이터 연결, 위험도 결정, 코드 수정안과 WAF 규칙 제안, 문법 검사와 시험 자료 검증, 고객 검토와 배포 결정 순서입니다. 해설: 검증을 통과해도 고객 환경이 저절로 바뀌지 않으며, 검사가 실패하거나 결과가 모호하면 제안은 고객 검토 전에 보류됩니다.

3번 정답: 근거 있는 범위 설정이 어렵기 때문입니다. 해설: Cloudflare는 이런 경우 규칙을 제안하지 않는다고 설명합니다.

참고자료

• WAF 입문 참고자료
• WAF 입문 참고자료
• WAF 입문 참고자료