Post

Web Application Firewall (WAF)

Posted
By Hyoeun Choi
35 min read
Web Application Firewall (WAF)

What is a WAF?

A WAF (Web Application Firewall) is a security solution that operates at OSI Layer 7 (the Application Layer), specializing in detecting and blocking specific attacks against web applications by directly inspecting the content (Payload) of web traffic.

This is fundamentally different from a Network Firewall, which controls traffic based on IPs and ports at Layers 3 and 4. If a network firewall is a ‘building security guard’ controlling traffic on all ports like SSH (22) and FTP (21), a WAF is like a ‘dedicated VIP bodyguard’ that only analyzes HTTP (80) and HTTPS (443) traffic to find specific threats like SQL Injection. In other words, a WAF does not inspect other protocols and focuses exclusively on analyzing web traffic.

How a WAF Works: Two Security Models

A WAF primarily uses two security models to determine if web traffic is malicious.

1. Negative Security Model (Blacklist Approach)

This approach is based on the principle of “block all known malicious patterns.” The WAF uses a predefined database of attack signatures, and if an incoming request matches one of these patterns, it is blocked. This model is easy to manage but is vulnerable to unknown attacks (Zero-days).

2. Positive Security Model (Whitelist Approach)

This is a very strict approach based on the principle of “block everything except for allowed requests.” While it offers high security, it is complex to operate and has a higher potential for false positives, as the allowance policies must be configured with great precision.

Major Attacks Blocked by WAFs

A WAF can effectively defend against most of the major web vulnerability attacks defined in the OWASP Top 10.

  • SQL Injection: Attacking a database by inserting malicious SQL queries.
  • Cross-Site Scripting (XSS): Stealing user information by injecting malicious scripts into a website.
  • Path Traversal: Accessing restricted system files using non-standard directory paths.
  • Command Injection: Executing arbitrary system commands on the server via the web application.

The Attacker’s Perspective: WAF Evasion Techniques

A WAF is fundamentally a rule-based system that identifies known attack patterns (signatures). Therefore, attackers attempt to bypass it by either neutralizing its rules or exploiting areas that the WAF does not understand.

1. Obfuscation: Neutralizing Signatures

This is the most basic and widely used evasion technique. It involves transforming malicious strings that a WAF looks for (e.g., SELECT, <script>) into a different form that the WAF doesn’t recognize but that the web server or browser can still interpret correctly.

  • Encoding: Tricking the WAF by representing the same characters in different ways.
    • Attack Payload: <script>alert('XSS')</script>
    • Evasion Attempt (URL Encoding): %3cscript%3ealert('XSS')%3c/script%3e
    • Evasion Attempt (HTML Encoding): &lt;script&gt;alert('XSS')&lt;/script&gt;
  • Case Alternation: Bypassing case-sensitive WAF detection rules.
    • Attack Payload: ' union select 1,2,3 --
    • Evasion Attempt: ' uNiOn sElEcT 1,2,3 --
  • Using Comments/Whitespace: Interfering with the WAF’s pattern recognition by inserting comments or special whitespace characters that are ignored by the database or script engine.
    • Attack Payload: select user,pass from users
    • Evasion Attempt (MySQL Comment): select/**/user,pass/**/from/**/users
  • String Splitting and Concatenation: Splitting a malicious string into multiple parts and having it be reassembled by the server or browser.
    • Attack Payload (JavaScript): alert('XSS')
    • Evasion Attempt: eval(String.fromCharCode(97, 108, 101, 114, 116, 40, 39, 88, 83, 83, 39, 41))

      The code above converts ‘alert(‘XSS’)’ into ASCII character codes and then executes it with the eval function, preventing the WAF from directly detecting the string ‘alert’.

2. HTTP Parameter Pollution (HPP): Causing Parser Confusion

This technique exploits the differences in parsing between a WAF and a web server by sending multiple parameters with the same name in a single HTTP request.

For example, a PHP/Apache server, by default, uses the last value of a duplicated parameter, whereas ASP.NET concatenates all values with a comma.

  • Scenario: Attempting an SQL injection on the productID parameter.
  • WAF-Blocked Payload: ?productID=1' and '1'='1

  • HPP Evasion Attempt: ?productID=1&productID=1' and '1'='1

  • How it works:
    1. The WAF inspects the first parameter, productID=1. Seeing no threat, it allows the request to pass.
    2. The PHP/Apache-based web server processes the last parameter, productID=1' and '1'='1, as the final value.
    3. As a result, the WAF fails to detect the threat, but the SQL injection attack succeeds on the server.

3. Business Logic Vulnerabilities: The WAF’s Blind Spot

This is the most difficult type of attack for a WAF to detect because it doesn’t rely on technical patterns like SQL injection but instead exploits the normal functions and flows of an application. A WAF cannot understand the business context that ‘this feature is not supposed to be used this way.’

  • Scenario 1: Shopping Mall Price Manipulation
    1. A user adds a $100 item to their shopping cart.
    2. The HTTP request to the payment page includes parameters like item_id=A123&price=100000.
    3. The attacker intercepts this request and modifies the price value to 1. (item_id=A123&price=1)
    4. WAF’s Verdict: This request contains no malicious scripts or SQL syntax. The only change is the numerical value from 100000 to 1. From the WAF’s perspective, this is perfectly normal traffic.
    5. Server’s Response: If the server trusts the price value sent by the client without a server-side validation logic, the attacker successfully purchases the $100 item for $0.01.
  • Scenario 2: Abusing the Password Reset Feature Assume a password reset process follows three steps: ① Enter ID → ② Identity Verification → ③ Change Password. If an attacker can save the legitimate response value after step ①, then manipulate and send it with another user’s ID during step ③ to bypass the verification step, this is a clear logic attack that a WAF cannot detect.

4. HTTP Request Smuggling

This is an advanced attack that exploits discrepancies in how a WAF and the back-end web server interpret an HTTP request. The attacker sends a deliberately ambiguous and manipulated HTTP request.

  • How it works: An attacker sends a non-standard request that includes both a Content-Length header and a Transfer-Encoding: chunked header.
    • WAF’s Verdict: The WAF interprets this as a single, legitimate request and lets it pass.
    • Web Server’s Verdict: The web server misinterprets this as two separate requests. The first is processed normally, and the second, hidden (smuggled) request is prepended to the next legitimate user’s request and processed.
  • Result: The WAF completely fails to inspect the second, smuggled request, allowing any malicious payload within it to be executed directly by the server. It’s like a magic box that appears as one package at the security checkpoint but splits into two inside.

5. Abusing Modern Protocols/APIs

Many older or improperly configured WAFs cannot fully understand and analyze modern technologies like WebSocket or GraphQL.

  • WebSocket: The initial connection begins over HTTP, but once established, it becomes a bidirectional communication tunnel. If the WAF only inspects the initial connection request and fails to properly inspect the encrypted message frames passing through the tunnel, an attacker can freely transmit malicious payloads.
  • GraphQL: Unlike REST APIs, GraphQL allows the client to request the exact structure of data it needs. An attacker can intentionally send deeply nested and complex queries to overload the server, causing a Denial of Service (DoS) attack. A WAF may struggle to identify this as malicious because the query is syntactically valid.

6. Resource Exhaustion

This technique aims to disrupt the normal operation of a WAF by exhausting its own CPU or memory resources.

  • How it works: An attacker might send a massive POST request (dozens of MB) or transmit a string with a complex pattern that puts a severe load on the WAF’s regular expression (Regex) engine.
  • Result: If the WAF consumes too many resources analyzing a request, it may enter a ‘Fail-Open’ state to preserve system-wide availability, allowing all traffic to pass through uninspected. At this moment, the WAF is effectively neutralized.

7. Architecture Bypass

This is the most fundamental method, which involves finding a path to the web server that doesn’t go through the WAF at all.

  • How it works: A WAF typically acts as a proxy that receives traffic in front of the web server. If the server’s real IP address is exposed through DNS records, email headers, or SSL certificate information, an attacker can bypass the WAF and send malicious requests directly to this IP.
  • Result: No matter how powerful a WAF is, it is useless if traffic doesn’t pass through it.

These diverse WAF evasion techniques demonstrate that a WAF alone cannot provide perfect defense. This is why it is always essential to establish a multi-layered security strategy from a Defense in Depth perspective.

Evasion Defense Strategies

Defending against WAF evasion techniques requires more than just turning on a WAF; it demands a multi-layered and continuous effort. Defense strategies can be broadly divided into hardening the WAF itself and defending beyond the WAF at the architecture and application levels.

1. WAF Operations and Rule Hardening

These are strategies to directly tune and strengthen the WAF to prevent evasion.

  • Enable Normalization This is the most effective way to block obfuscation attacks. Normalization is the process where the WAF restores all input values—such as URL-encoded or HTML-encoded data—to their original form and standardizes casing before inspection. For example, modified attack strings like %3cscript%3e or <sCrIpT> are all converted back to <script>, allowing the WAF to detect them based on a consistent standard.

  • Understand Modern Protocols/APIs If you use WebSocket or GraphQL, you must deploy a modern WAF that can parse the content of their traffic. Older WAFs do not understand them properly, so you should choose a WAF that includes API security gateway features or deploy an additional specialized solution.

  • Enforce Strict Protocol Rules To prevent attacks like HTTP Request Smuggling, WAF policies should be hardened to block non-standard HTTP requests that violate RFC standards (e.g., requests containing both Content-Length and Transfer-Encoding headers).

  • Set Resource Limits and a Fail-Close Configuration To block resource exhaustion attacks, you must strictly limit the maximum size of HTTP requests, the number of parameters, etc. Furthermore, instead of a ‘Fail-Open’ setting that lets all traffic pass when the WAF is overloaded, you should configure a ‘Fail-Close’ setting that blocks all traffic, prioritizing security over availability.

2. Architecture and Application-Level Defense

These are fundamental Defense in Depth strategies for blocking attacks that a WAF can never stop on its own.

  • Hide the Origin Server IP (Origin IP Protection) This is the core defense against architecture bypass attacks. When using a cloud-based WAF like Cloudflare or AWS WAF, you must configure the web server’s firewall to only allow traffic from the IP ranges of that WAF (CDN) service and block all other traffic. This makes direct access impossible even if an attacker discovers the real server IP.

  • Secure Coding This is the only and most certain way to fix business logic vulnerabilities. A WAF does not understand application logic, so security must be considered from the development stage.

    • Server-Side Validation: All critical data and logic, such as item prices and user permissions, must be validated on the server side. Never trust values sent by the client.
    • Input Validation: Thoroughly validate the data type, length, and allowed characters for all user inputs on the server.

WAF and Privacy: An Essential Consideration

To inspect payload content, a WAF must decrypt encrypted HTTPS traffic. This means the WAF can see all data sent by users in plaintext, including IDs, passwords, and personal information, which can create privacy issues.

Therefore, a balance between security and privacy is crucial when operating a WAF.

  • Minimize Sensitive Information Logging: While the WAF inspects data to detect threats, it is essential to mask Personally Identifiable Information (PII) like passwords and credit card numbers so they are not stored in logs.
  • Ensure Legal Compliance and Access Control: You must comply with data protection regulations like GDPR, restrict the number of administrators who can access WAF logs to a minimum, and log and audit all access.

Conclusion: A WAF is Not a Silver Bullet

A WAF is an essential first line of web security defense, but it is by no means a silver bullet. Evasion techniques are constantly evolving, and issues like business logic flaws or privacy concerns cannot be solved by a WAF alone.

The most effective security strategy is to use a WAF as one component of a Defense in Depth strategy. This means building a multi-layered defense system by combining a WAF with Secure Coding, regular vulnerability assessments, and strict privacy protection policies.

WAF란 무엇인가?

WAF는 OSI 7계층(애플리케이션 계층)에서 작동하는 보안 솔루션으로, 웹 트래픽의 내용(Payload) 을 직접 검사하여 웹 애플리케이션에 대한 특정 공격을 탐지하고 차단하는 데 특화되어 있습니다.

이는 3, 4계층에서 IP와 포트 기반으로 트래픽을 제어하는 네트워크 방화벽과는 근본적으로 다릅니다. 네트워크 방화벽이 SSH(22), FTP(21) 등 모든 포트의 트래픽을 제어하는 ‘건물 경비원’이라면, WAF는 오직 HTTP(80), HTTPS(443) 트래픽만을 분석하여 SQL 인젝션 같은 특정 위협을 찾아내는 ‘VIP 전담 경호원’과 같습니다. 즉, WAF는 다른 프로토콜은 검사하지 않으며 오직 웹 트래픽 분석에만 집중합니다.

WAF의 작동 원리: 두 가지 보안 모델

WAF는 크게 두 가지 보안 모델을 기반으로 웹 트래픽의 유해성을 판단합니다.

1. 네거티브 보안 모델 (블랙리스트 방식)

“알려진 악성 패턴을 모두 차단한다”는 접근 방식입니다. WAF는 사전에 정의된 공격 시그니처(Signature) 데이터베이스를 기반으로, 들어오는 요청이 이 패턴과 일치하면 차단합니다. 관리가 쉽지만 알려지지 않은 공격(Zero-day)에는 취약합니다.

2. 포지티브 보안 모델 (화이트리스트 방식)

“허용된 요청 외에는 모두 차단한다”는 매우 엄격한 접근 방식입니다. 보안성은 높지만, 허용 정책을 정교하게 설정해야 하므로 운영이 복잡하고 오탐의 가능성이 있습니다.

WAF가 막아내는 주요 공격들

WAF는 OWASP Top 10 에서 정의하는 대부분의 주요 웹 취약점 공격을 효과적으로 방어할 수 있습니다.

  • SQL 인젝션 (SQL Injection): 악의적인 SQL 구문을 삽입하여 데이터베이스를 공격
  • 크로스 사이트 스크립팅 (XSS): 웹사이트에 악성 스크립트를 삽입하여 사용자 정보를 탈취
  • 경로 조작 (Path Traversal): 비정상적인 경로로 접근이 제한된 시스템 파일에 접근
  • 명령어 삽입 (Command Injection): 웹을 통해 서버에 임의의 시스템 명령어를 실행

공격자의 관점: WAF 우회 기법

WAF는 기본적으로 알려진 공격 패턴(시그니처)을 찾아내는 규칙 기반의 시스템입니다. 따라서 공격자들은 WAF의 규칙을 무력화하거나, WAF가 이해하지 못하는 영역을 공략하는 방식으로 우회를 시도합니다.

1. 난독화 (Obfuscation): 시그니처 무력화

가장 기본적이고 널리 사용되는 우회 기법입니다. WAF가 탐지하려는 악성 문자열(SELECT, <script> 등)을 WAF는 모르지만 웹 서버나 브라우저는 이해할 수 있는 다른 형태로 변형하는 방식입니다.

  • 인코딩(Encoding): 같은 문자도 다르게 표현하여 WAF를 속입니다.
    • 공격 페이로드: <script>alert('XSS')</script>
    • 우회 시도 (URL 인코딩): %3cscript%3ealert('XSS')%3c/script%3e
    • 우회 시도 (HTML 인코딩): &lt;script&gt;alert('XSS')&lt;/script&gt;
  • 케이스 변경(Case Alternation): WAF의 탐지 규칙이 대소문자를 구분하는 경우 이를 우회합니다.
    • 공격 페이로드: ' union select 1,2,3 --
    • 우회 시도: ' uNiOn sElEcT 1,2,3 --
  • 주석/공백 활용: 데이터베이스나 스크립트 엔진이 무시하는 주석이나 특수 공백 문자를 삽입하여 WAF의 패턴 인식을 방해합니다.
    • 공격 페이로드: select user,pass from users
    • 우회 시도 (MySQL 주석): select/**/user,pass/**/from/**/users
  • 문자열 분할 및 조합: 악성 문자열을 여러 개로 쪼갠 후 서버나 브라우저에서 다시 조합되도록 만듭니다.
    • 공격 페이로드 (JavaScript): alert('XSS')
    • 우회 시도: eval(String.fromCharCode(97, 108, 101, 114, 116, 40, 39, 88, 83, 83, 39, 41))

      위 코드는 ‘alert(‘XSS’)’를 아스키 코드로 변환한 후 eval 함수로 실행시켜 WAF가 ‘alert’라는 문자열을 직접 탐지하지 못하게 합니다.

2. HTTP 파라미터 오염 (HPP): 파서 혼란 유발

하나의 HTTP 요청에 동일한 이름의 파라미터를 여러 번 전송하여, WAF와 웹 서버 간의 파싱(Parsing) 방식 차이를 악용하는 기법입니다.

예를 들어, PHP/Apache 서버는 기본적으로 동일한 이름의 파라미터 중 마지막 값을 사용하고, ASP.NET은 모든 값을 쉼표로 연결하여 사용합니다.

  • 시나리오: productID 파라미터에 대한 SQL 인젝션을 시도
  • WAF 차단 페이로드: ?productID=1' and '1'='1

  • HPP 우회 시도: ?productID=1&productID=1' and '1'='1

  • 작동 방식:
    1. WAF는 첫 번째 파라미터인 productID=1을 검사합니다. 특별한 위협이 없으므로 요청을 통과시킵니다.
    2. PHP/Apache 기반의 웹 서버는 마지막 파라미터인 productID=1' and '1'='1을 최종값으로 인식하고 처리합니다.
    3. 결과적으로 WAF는 위협을 탐지하지 못했지만, 서버에서는 SQL 인젝션 공격이 성공하게 됩니다.

3. 비즈니스 로직 취약점: WAF의 사각지대

WAF가 가장 탐지하기 어려운 공격입니다. 이는 SQL 인젝션처럼 기술적인 패턴이 아니라, 애플리케이션의 정상적인 기능과 흐름을 악용하는 방식이기 때문입니다. WAF는 ‘이 기능이 원래 이렇게 쓰이면 안 된다’는 비즈니스 맥락을 이해하지 못합니다.

  • 시나리오 1: 쇼핑몰 가격 조작
    1. 사용자가 100,000원짜리 상품을 장바구니에 담습니다.
    2. 결제 페이지로 넘어가는 HTTP 요청에는 item_id=A123&price=100000 와 같은 파라미터가 포함됩니다.
    3. 공격자는 이 요청을 중간에서 가로채 price 값을 1로 수정하여 전송합니다. (item_id=A123&price=1)
    4. WAF의 판단: 이 요청에는 어떠한 악성 스크립트나 SQL 구문도 없습니다. 숫자 값이 100000에서 1로 바뀐 것일 뿐, WAF 입장에서는 완벽하게 정상적인 트래픽입니다.
    5. 서버의 반응: 만약 서버가 가격을 검증하는 로직 없이 클라이언트가 보낸 price 값을 그대로 신뢰한다면, 공격자는 100,000원짜리 상품을 1원에 구매하게 됩니다.
  • 시나리오 2: 비밀번호 찾기 기능 악용 비밀번호 찾기 기능이 ① 아이디 입력 → ② 본인 인증 → ③ 비밀번호 변경 순서로 진행된다고 가정합시다. 만약 공격자가 ① 단계 후 정상적인 응답 값을 저장해두었다가, ③ 단계에서 다른 사용자의 아이디와 함께 조작된 응답 값을 전송하여 인증 단계를 건너뛸 수 있다면, 이는 WAF가 탐지할 수 없는 명백한 로직 공격입니다.

4. HTTP 요청 스머글링 (HTTP Request Smuggling) smuggling

이 기법은 WAF와 그 뒤에 있는 웹 서버가 HTTP 요청을 해석하는 방식의 차이를 악용하는 고도화된 공격입니다. 공격자는 일부러 모호하게 조작된 HTTP 요청을 보냅니다.

  • 작동 방식: 공격자는 Content-Length 헤더와 Transfer-Encoding: chunked 헤더를 모두 포함하는 비정상적인 요청을 보냅니다.
    • WAF의 판단: WAF는 이 요청을 하나의 정상적인 요청으로 해석하고 통과시킵니다.
    • 웹 서버의 판단: 웹 서버는 이 요청을 두 개의 요청으로 잘못 해석합니다. 첫 번째 요청은 정상 처리되고, 두 번째 숨겨진(smuggled) 요청은 다음 사용자의 정상적인 요청 앞에 붙어서 처리됩니다.
  • 결과: WAF는 숨겨진 두 번째 요청을 전혀 검사하지 못했기 때문에, 이 요청에 담긴 악성 페이로드가 그대로 서버에서 실행됩니다. 마치 보안검색대에서는 하나의 상자로 보였지만, 내부에서는 두 개로 분리되는 마술 상자와 같습니다.

5. 최신 프로토콜/API 악용 (Abusing Modern Protocols/APIs)

많은 구형 WAF나 제대로 설정되지 않은 WAF는 WebSocket이나 GraphQL과 같은 최신 기술을 완벽하게 이해하고 분석하지 못합니다.

  • WebSocket: 최초 연결은 HTTP로 시작하지만, 한번 연결이 수립되면 양방향 통신 터널이 됩니다. WAF가 초기 연결 요청만 검사하고 터널 내부로 오가는 암호화된 메시지 프레임은 제대로 검사하지 못하는 경우, 공격자는 이 터널을 통해 악성 페이로드를 자유롭게 전송할 수 있습니다.
  • GraphQL: REST API와 달리, GraphQL은 클라이언트가 원하는 데이터의 구조를 직접 요청할 수 있습니다. 공격자는 일부러 매우 복잡하고 깊게 중첩된 쿼리를 보내 서버에 과부하를 일으켜 서비스 거부(DoS) 공격을 유발할 수 있습니다. WAF는 이 쿼리가 문법적으로는 정상이므로 악의적인 것으로 판단하기 어렵습니다.

6. 리소스 고갈 공격 (Resource Exhaustion)

WAF 자체의 CPU나 메모리 자원을 고갈시켜 정상적인 작동을 방해하는 기법입니다.

  • 작동 방식: 공격자는 수십 MB에 달하는 거대한 POST 요청을 보내거나, WAF의 정규식(Regex) 엔진에 심각한 부하를 주는 복잡한 패턴의 문자열을 전송합니다.
  • 결과: WAF가 요청을 분석하는 데 너무 많은 자원을 소모하게 되면, 시스템 전체의 가용성을 위해 스스로 검사를 포기하고 모든 트래픽을 그대로 통과시키는 ‘Fail-Open’ 상태로 전환될 수 있습니다. 이 순간 WAF는 사실상 무력화됩니다.

7. 아키텍처 우회 (Architecture Bypass)

가장 근본적인 방법으로, WAF를 아예 거치지 않고 웹 서버에 직접 접근하는 경로를 찾아내는 것입니다.

  • 작동 방식: WAF는 보통 웹 서버 앞단에서 트래픽을 받는 프록시(Proxy) 역할을 합니다. 만약 DNS 기록, 이메일 헤더, SSL 인증서 정보 등을 통해 웹 서버의 실제 IP 주소가 외부에 노출되어 있다면, 공격자는 WAF를 우회하여 이 IP로 직접 악성 요청을 보낼 수 있습니다.
  • 결과: WAF가 아무리 강력해도, 트래픽이 자신을 거쳐 가지 않으면 아무런 의미가 없습니다.

이처럼 WAF 우회 기법은 매우 다양하며, 이는 WAF 하나만으로는 완벽한 방어가 불가능하다는 것을 보여줍니다. 항상 심층 방어(Defense in Depth) 관점에서 다층적인 보안 전략을 수립해야 하는 이유입니다.

우회 방어 전략

WAF 우회 기법들을 방어하는 것은 단순히 WAF의 기능을 켜두는 것 이상의, 다층적이고 지속적인 노력이 필요합니다. 방어 전략은 크게 WAF 자체를 고도화하는 것과 WAF를 넘어선 아키텍처 및 애플리케이션 레벨에서 방어하는 것으로 나눌 수 있습니다.

1. WAF 운영 및 규칙 고도화

WAF가 우회되지 않도록 직접 튜닝하고 강화하는 전략입니다.

  • 정규화(Normalization) 기능 활성화 난독화 공격을 막는 가장 효과적인 방법입니다. 정규화는 WAF가 모든 입력값을 검사하기 전에 URL 인코딩, HTML 인코딩 등을 모두 원본 형태로 복원하고, 대소문자를 통일하는 과정입니다. 예를 들어 %3cscript%3e나 <sCrIpT> 같은 변형된 공격 구문도 정규화를 거치면 모두 <script>로 변환되어, WAF가 일관된 기준으로 탐지할 수 있게 됩니다.

  • 최신 프로토콜/API에 대한 이해 WebSocket이나 GraphQL을 사용한다면, 해당 트래픽의 내용을 분석할 수 있는 최신 WAF를 도입해야 합니다. 구형 WAF는 이들을 제대로 이해하지 못하므로, API 보안 게이트웨이 기능이 포함된 WAF를 선택하거나 전문 솔루션을 추가로 도입해야 합니다.

  • 엄격한 프로토콜 규칙 적용 HTTP 요청 스머글링과 같은 공격을 방지하기 위해, RFC 표준을 위반하는 비정상적인 HTTP 요청(예: Content-Length와 Transfer-Encoding이 모두 포함된 요청)을 아예 차단하도록 WAF 정책을 강화해야 합니다.

  • 리소스 제한 및 Fail-Close 설정 리소스 고갈 공격을 막기 위해 HTTP 요청의 최대 크기, 파라미터 개수 등을 엄격하게 제한해야 합니다. 또한, WAF에 과부하가 걸렸을 때 모든 트래픽을 통과시키는 ‘Fail-Open’ 대신, 모든 트래픽을 차단하는 ‘Fail-Close’ 방식으로 설정하여 가용성보다 보안을 우선해야 합니다.

2. 아키텍처 및 애플리케이션 레벨 방어

WAF만으로는 절대 막을 수 없는 공격들을 방어하기 위한, 더 근본적인 심층 방어(Defense in Depth) 전략입니다.

  • 실제 서버 IP 숨기기 (Origin IP Protection) 아키텍처 우회 공격을 막는 핵심 방어법입니다. Cloudflare나 AWS WAF 같은 클라우드 기반 WAF를 사용할 경우, 웹 서버의 방화벽에서 오직 해당 WAF(CDN) 서비스의 IP 대역에서 오는 트래픽만 허용하고 나머지는 모두 차단해야 합니다. 이렇게 하면 공격자가 실제 서버 IP를 알아내도 직접적인 접근이 불가능해집니다.

  • 시큐어 코딩 (Secure Coding) ** **비즈니스 로직 취약점을 해결할 수 있는 유일하고 가장 확실한 방법입니다. WAF는 애플리케이션의 논리를 이해하지 못하므로, 개발 단계에서부터 보안을 고려해야 합니다.

    • 서버 측 검증(Server-Side Validation): 상품 가격, 사용자 권한 등 모든 중요한 데이터와 로직은 반드시 서버 측에서 검증해야 합니다. 클라이언트가 보낸 값을 절대로 신뢰해서는 안 됩니다.
    • 입력값 검증: 모든 사용자 입력값에 대해 데이터 타입, 길이, 허용 문자 등을 서버에서 철저히 검사해야 합니다.

WAF와 프라이버시: 반드시 고려해야 할 문제

WAF는 페이로드 내용을 검사하기 위해 암호화된 HTTPS 트래픽을 복호화해야 합니다. 이는 WAF가 ID, 비밀번호, 개인정보 등 사용자가 보내는 모든 데이터를 원문 그대로 볼 수 있다는 뜻이며, 프라이버시 문제를 야기할 수 있습니다.

따라서 WAF를 운영할 때는 보안과 프라이버시 간의 균형이 매우 중요합니다.

  • 민감 정보 로깅 최소화: WAF는 위협을 탐지하기 위해 데이터를 검사하되, 비밀번호나 신용카드 번호와 같은 개인 식별 정보(PII)는 로그에 저장하지 않도록 마스킹 처리하는 것이 필수입니다.
  • 법규 준수 및 접근 통제: GDPR과 같은 개인정보보호 규제를 준수해야 하며, WAF 로그에 접근할 수 있는 관리자를 최소한으로 제한하고 모든 접근을 기록 및 감사해야 합니다.

결론: WAF는 만능 해결책이 아니다

WAF는 웹 보안의 필수적인 첫 번째 방어선이지만, 결코 만능 해결책(Silver Bullet)이 아닙니다. 우회 기법은 계속해서 발전하고, 비즈니스 로직의 허점이나 프라이버시 문제는 WAF만으로 해결할 수 없습니다.

가장 효과적인 보안 전략은 WAF를 심층 방어(Defense in Depth) 전략의 한 요소로 활용하는 것입니다. 즉, WAF와 더불어 시큐어 코딩(Secure Coding), 정기적인 취약점 진단, 그리고 엄격한 프라이버시 보호 정책을 함께 적용하여 다층적인 방어 체계를 구축해야 합니다.

Cybersecurity, Web Security
WAF
This post is licensed under CC BY 4.0 by the author.