Security

WAF 생태계 전반의 문제, 런타임 보안으로 보충해야

문가용 기자

Published: 12:26, 19 Dec 2025 (Updated: 16:40, 14 Jan 2026)

💡

Editor's Pick
- WAF 대부분 디폴트 상태로는 CVE 절반만 방어 가능
- WAF 개발사들, 새 CVE 나왔을 때 규칙 업데이트 늦어
- WAF도 유지하고, 런타임 보안 기능도 확대시켜야

웹 애플리케이션 방화벽에 흔히 설정하는 주요 규칙들이 매우 허술하다는 연구 결과가 나왔다. 보안 기업 미고시큐리티(Miggo Security)가 발표한 바에 따르면 “이미 알려진 주요 취약점 익스플로잇 기법 중 절반 이상을 막지 못한다”고 한다. 360개가 넘는 CVE를 주요 웹 애플리케이션 방화벽 플랫폼들에 대입하여 얻어낸 결과라고 한다. 실험에 사용된 취약점들은 2024년 1월 이후에 발견된 것들이다.

특정 앱이나 플랫폼이 아니라 생태계 전반의 문제

어떤 웹 애플리케이션 방화벽(이후 WAF)이 문제가 됐을까? 미고 측은 이번에 실험 대상이 된 제품이나 플랫폼을 개별적으로 공개하지는 않고 있다. “특정 제품을 겨냥한 실험이 아니었기 때문입니다. 저희는 WAF 생태계 전반에 이러한 문제가 있다는 걸 드러내고 싶었습니다. 실제 실험 결과도 그렇게 나왔고요. WAF의 규칙들이 지금은 매우 취약한 상황입니다.”

그 ‘취약한 상황’이라는 것은 정확히 말해 “현재 기본 설정 상태로 배포되고 있는 WAF들은 현존하는 CVE 익스플로잇의 절반 정도(48%)만 차단한다는 것”이다. 그렇다고 현재 시장에 나와 있는 WAF들의 성능이 심각하게 부족하다는 뜻은 아니다. 오히려 그 반대라고 미고시큐리티는 강조한다. “대부분의 취약점들이 WAF만으로도 차단이 충분히 됩니다(80%). 다만 그런 WAF를 잘못 운영하기 때문에 막을 수 있는 취약점의 절반 이상을 막지 못하고 있는 겁니다.”

미고시큐리티 측은 현 상태로 막히는 CVE와 그렇지 않은 CVE를 따로 정리해 공개하지는 않았다. 특정 취약점들에만 시선이 집중되는 걸 막기 위해서다. “현재 생태계 전반적으로 퍼진 구조적 문제를 짚어내고 싶었습니다. 이런 문제를 취약점 몇 개 패치 정도로 접근해서는 안 됩니다.”

그럼에도 ‘힌트’는 공개됐다. “전통적인 ‘주입 공격’ 계열의 취약점은 현 상태로 잘 막히는 편입니다. 단순 SQL 주입 공격이라든가, OS 명령 주입 공격 등이 여기에 해당됩니다. URL과 매개변수를 기반으로 한 단순 공격을 유발하는 취약점도 잘 차단했습니다. 하지만 인증과 권한을 우회하게 하거나 특정 요청이 순서대로 입력되어야 익스플로잇 되는 취약점 등 애플리케이션 로직 단계에서 발생하는 것들은 잘 막지 못했습니다.”

고지도 너무 늦어

WAF 벤더들은 주요 취약점이 공개되면, 해당 CVE에 맞는 전용 규칙을 마련해 고객들이 적용할 수 있도록 게시해야 한다. 그런데 취약점 공개와 새 규칙 게시일까지 걸리는 시간이 평균 41일이라는 것이 이번 연구를 통해 밝혀졌다. “공격자들은 취약점이 공개되고서는 불과 몇 시간 후부터 활동을 시작하기도 합니다. 취약점마나 편차가 있다고는 하나, 41일이나 걸리지는 않습니다. 이 기간은 너무 길고, 방어라는 개념에 있어 비현실적이기까지 합니다.”

그러면서 마고 측에서 예를 든 것은 최근 크게 문제가 된 리액투셸(React2Shell) 취약점이다. “이 취약점의 경우 공개되고서 불과 수시간 만에 중국 내 해커들이 익스플로잇 하기 시작했습니다. 이런 사례는 차고 넘칩니다. 리액투셸에서만 나타난 독특한 현상이 아닙니다. 그러니 새 규칙과 패치의 배포 주기도 더 당겨져야 합니다.”

원흉은 WAF 개발사? 아니면 사용자?

여기까지의 지적을 보면 문제의 근원은 개발사인 것처럼 보인다. 개발사가 디폴트 정책을 잘 정리해서 WAF를 판매하고, 판매한 후에도 재깍재깍 탐지 규칙을 최신화 하면 해결될 것처럼 보이기 때문이다. 혹은 사용자가 WAF를 구축한 후 꾸준한 ‘미세 조정’을 통해 규칙을 강화하면 WAF를 보다 효과적으로 활용하는 것도 가능할 것 같다.

하지만 마고는 “어느 정도 개선에 이를 수 있는 방법인 건 맞지만 한계가 분명하다”고 말한다. “개발사가 정신 차리고, 사용자가 보안 의식 투철하게 행동하면 당연히 효과가 있을 겁니다. 하지만 WAF단에서 탐지하거나 차단해야 하는 CVE의 수는 연간 4만~5만개씩 늘어납니다. 1년은 365일이에요. ‘4만’은 하루에 CVE 110개 정도 대응해야 채워지는 숫자입니다. 어떤 개발사나 사용자 기업이 WAF 규칙을 하루에 100번 넘게 바꿀 수 있을까요?”

심지어 잘 탐지가 되지 않는 취약점 유형은 위에서 설명했다시피 ‘로직’과 관련된 것들이다. 패치만으로 수정이 어려운 것들이 있을 수 있다는 의미다. 그래서 미고시큐리티가 강조하는 것(그리고 요즘 보안 업계에서 화두가 되고 있는 것)이 “런타임 기반 보안”이다.

런타임 보안?

런타임 보안이라는 건 뭘 말하는 것일까? “런타임 보안 혹은 런타임 인지 방어는 애플리케이션이 실행되는 순간의 상태와 맥락을 기준으로 공격을 탐지하고 차단하는 것을 말합니다. ‘WAF 규칙’이라는 것은 정적인 것이고, 따라서 ‘체크리스트 보안’의 방식으로 시스템을 강화하죠. 시시각각 바뀌며 변주를 주는 오늘날의 위협을 막기에 이런 정적인 방법은 비효율적입니다. 좀 더 동적인 방어가 필요하고, 그것이 바로 런타임 보안입니다.”

그래서 런타임 보안 혹은 런타임 인지 방어에서는 정해진 규칙을 기반으로 현상을 관찰하거나 탐지하지 않는다. “애플리케이션의 실행 흐름을 봅니다. 즉 어떤 함수가 호출되는지, 평소와 다른 경로를 타고 있지는 않은지, 예외적인 코드 경로로 진입하는지를 살피죠. 또 사용자 인증이 되었는지, 세션이 어떤 상태인지, 이전에 어떤 요청이 있었고, 그것이 어떻게 처리됐는지까지도 파악합니다. 입력값이 다만 문법적으로 맞는지, 아니면 의미나 상황 전체를 고려해도 괜찮은지 등도 고려하여 다음 절차를 결정합니다.”

쉽게 말해 실시간으로 움직이는 자를 실시간으로 관찰해 잡아내는 게 런타임 보안이 추구하는 바라고 정리가 가능하다. 제대로 구현된다면 기존 WAF 규칙으로 잡아낼 수 없던 이상 현상을 정확하게 짚어낼 것이라고 보안 업계는 보고 있다. 문광석 보안 기술사도 지난 화요일 열린 ‘OWASP서울챕터 보안 송년회’에서 “런타임 보안이 화두”라며 “문지기가 체크리스트 들고 대문 하나 지키는 방식의 보안은 통하지 않는다”고 발표하기도 했었다. “지켜야 할 문이 20개씩 되니까요. 이제 그 문 안으로 시선을 돌려 어떤 것들이 어떻게 돌아가는지를 실시간으로 볼 수 있어야 합니다. 그게 보안의 할 일입니다.”

런타임 보안, 어떻게 구현하나?

마고시큐리티는 런타임 보안을 구현하는 대표적 방식으로 RASP를 꼽고 있다. ‘런타임 애플리케이션 자가 보호(Runtime Application Self-Protection)’의 준말이다. 애플리케이션 내부에 에이전트를 심고, 실행 중인 코드에 후킹을 걸어 위험한 동작을 실행 직전에 차단하는 기술이다. “커널과 런타임 층위에서 행위를 관찰하여 어떤 함수가 호출되고, 어떤 시스템 콜이 발생하는지, 메모리에 누가 어떤 권한으로 접근하는지 등을 실시간으로 파악하기도 합니다.”

런타임을 인공지능에 학습시키는 것도 가능하다. “정상적인 상태로 애플리케이션이 실행될 때의 패턴을 학습시킨 후, 비정상적인 상태에서 어떤 일이 일어나는지, 그 편차를 익히게 하는 방식입니다. 이렇게 훈련시킨 인공지능은 공격자가 기존 익스플로잇을 살짝 변형시켜도 탐지할 수 있게 됩니다.”

그렇다고 WAF가 필요 없는 건 아니다. “런타임 보안과 WAF는 각각 다른 역할을 수행하는 것이지, 서로를 대체하는 건 아닙니다. WAF는 대량의 저급 공격을 효과적으로 필터링 해줍니다. 런타임은 보다 정교한 공격을 차단하는 효과적이고요. 이 두 가지가 다 갖춰져야 아마추어의 대량 공격도 막고, 고급 해커의 최신식 응용 침해 시도도 막을 수 있게 됩니다.”🆃🆃🅔

by 문가용 기자(anotherphase@thetechedge.ai)