Regex 매칭에서 의도 이해까지: SafeLine WAF가 Semantic Analysis를 활용하는 방법

발행: 1주 전 (2025년 12월 17일 오후 04:44 GMT+9)

8 min read

Source: Dev.to

위 링크에 있는 전체 텍스트를 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록, URL 및 마크다운 형식은 그대로 유지됩니다.)

정규식 기반 WAF가 실제로 하는 일

대부분의 전통적인 WAF는 정규식을 사용해 공격을 탐지합니다. 규칙은 다음과 같이 보일 수 있습니다:

union[\w\s]*?select

의미: 트래픽에 union과 select가 모두 포함되어 있으면 SQL 인젝션으로 표시합니다.

또는 XSS의 경우:

\balert\s*\(

의미: 입력에 alert(가 포함되어 있으면 XSS로 처리합니다.

이 접근 방식은 간단하고 빠르기 때문에 ModSecurity와 같은 엔진이 크게 인기를 끌었습니다. 오늘날에도 많은 WAF가 이 모델을 기반으로 구축되어 있습니다.
하지만 단순함에는 대가가 따릅니다.

왜 정규식 기반 탐지는 실제로 실패하는가

1. 공격자는 적대적이다

실제 공격자는 여러분의 정규식 규칙에 맞는 페이로드를 작성하지 않는다. 그들은 우회하기 위한 페이로드를 만든다.

Original rule

union[\w\s]*?select

Bypass

union/**/select

SQL 의미는 동일하지만 키워드 패턴이 깨진다.

Original rule

\balert\s*\(

Bypass

window['\x61lert']()

브라우저는 이를 정상적으로 실행하고, 정규식은 alert(를 전혀 보지 못한다.

2. 정규식은 대량의 오탐을 일으킨다

정규식 규칙은 의미를 이해하지 못한다. 단지 패턴만 매칭한다.

Example (SQL)

The union select members from each department to form a committee.

일반 영어 문장이지만 union과 select가 매칭되어 SQL 인젝션으로 차단될 수 있다.

Example (XSS)

Her down on the alert (for the man) and walked into a world of rivers.

일반 텍스트이지만 여전히 순진한 XSS 규칙을 트리거한다.

결과

실제 공격은 여전히 통과한다
정상 사용자는 차단된다
엔지니어는 근본 원인을 해결하기보다 규칙을 조정하는 데 시간을 쏟는다

이 때문에 정규식 기반 WAF는 종종 양쪽 모두에서 항상 틀렸다고 느껴진다.

WAF 컨텍스트에서 의미 분석이 의미하는 바

의미 분석은 묻지 않는다:

“이 입력이 공격처럼 보이나?”

대신에 묻는다:

“이 입력이 실행 가능한 논리로서 의미가 있는가, 그렇다면 무엇을 하려는가?”

SafeLine WAF는 이 아이디어를 기반으로 구축되었습니다.

의미론적 관점에서 본 SQL 인젝션

SQL 인젝션이 실제로 성립하려면 두 가지 조건을 만족해야 합니다.

1. 입력은 유효한 SQL이어야 함 (구문적으로)

유효한 SQL 조각

union select username from users where

잘못된 SQL 조각

union select username from users users users where

SQL로 파싱되지 않으면, 키워드가 얼마나 의심스러워도 SQL 인젝션이 될 수 없습니다.

2. SQL에 악의적인 의도가 있어야 함

union select password from users

명백히 악의적입니다.

1 + 1 = 2

유효한 SQL이지만, 공격 관점에서는 의미가 없습니다.

의미 분석은 두 경우를 구분합니다.

SafeLine WAF가 공격을 의미론적으로 감지하는 방법

HTTP 요청을 파싱하고 모든 사용자 제어 입력을 찾습니다.
페이로드를 재귀적으로 디코드합니다 (URL 인코딩, 유니코드, Base64, 난독화 등).
언어 컨텍스트 식별 (SQL, JavaScript, HTML, 템플릿 구문 등).
- 언어 인식 파서/컴파일러를 사용해 입력을 파싱합니다.
의미적 의도 분석 (데이터 유출, 코드 실행, 컨텍스트 탈출 등).
실제 공격 행동을 기반으로 위협 점수 부여.
키워드가 아니라 위험도에 따라 허용 또는 차단.

SafeLine은 단순히 문자열을 매칭하는 것이 아니라 구조와 의도를 이해합니다.

Source: …

왜 의미 분석이 정규식보다 근본적으로 강력한가

이것은 단순한 의견이 아닙니다. 컴퓨터 과학에 기반을 두고 있습니다.

간단한 컴파일러 이론 우회

촘스키 계층에 따르면, 형식 언어는 네 가지 클래스로 나뉩니다:

유형	문법	인식 장치
0	제한 없음	튜링 머신
1	문맥‑민감	선형 제한 자동기
2	문맥‑자유	푸시다운 자동기
3	정규	유한 자동기

SQL, JavaScript, HTML → 유형 2 (또는 그 이상)
정규 표현식 → 유형 3만

왜 이것이 중요한가

정규 표현식은 카운트하거나 중첩할 수 없습니다. 전형적인 예:

((()))   ✅
(()())   ✅
(()      ❌

정규식이 괄호가 균형을 이루는지를 신뢰할 수 없는데, 복잡하고 중첩된 공격 페이로드를 정확히 모델링하도록 기대하는 것은 비현실적입니다.

핵심 문제

당신은 더 강력한 언어(유형 2 이상)로 작성된 공격을 탐지하기 위해 가장 약한 언어 클래스(유형 3)를 사용하고 있습니다.

요약

Regex‑based WAFs는 빠르지만 취약합니다: 우회와 오탐을 발생시킵니다.
Semantic analysis는 입력의 의미를 평가하여, 거짓 음성 및 거짓 양성을 크게 감소시킵니다.
SafeLine WAF는 현대적인 언어 인식 접근 방식이 무한한 규칙 튜닝 사이클 없이 애플리케이션을 보호할 수 있음을 보여줍니다.

패턴 매칭에서 의도 이해로 전환함으로써, 조직은 실제 환경에서 작동하는 WAF를 마침내 얻을 수 있습니다.

# SafeLine WAF: From Pattern Matching to Intent Understanding

SafeLine WAF represents a shift in defense philosophy:

- ❌ **Not** “does this string contain bad words?”
- ✅ **Yes** – “does this input form executable logic?”
- ✅ **Yes** – “what is the attacker trying to achieve?”

The Result

Significantly harder to bypass
Dramatically fewer false positives
Detection aligned with how real attacks work

Modern web attacks are programs, not just strings.
If attackers use programming languages to build payloads, defenders need systems that can understand those languages, not merely match keywords.

That’s why semantic analysis isn’t just an optimization — it’s a necessity.

Official Website: