NGINX One – F5 WAF for NGINX Cookie Policy 구성 가이드

이번 포스트에서는 NGINX One Console에서 F5 WAF for NGINX의 cookie name별로 다른 정책을 적용하는 방법을 실제 구성과 테스트 결과를 통해 설명합니다. 특히 session_id처럼 민감한 쿠키는 강력하게 보호하고, tracking_* 같은 마케팅 쿠키는 검사 없이 통과시키는 등, 실무에서 자주 필요한 쿠키별 차등 정책을 구현하는 방법을 다룹니다.

기본 정책은 쿠키 무결성 보호에 집중되어 있지만, 특정 쿠키 이름에 대해서는 allow/enforce를 선택적으로 적용하고, 세부적인 보안 속성도 쿠키별로 제어할 수 있습니다.

목차

1. 전체 쿠키 정책 구성 요약
2. 각 쿠키별 정책 작동 방식 및 구성 이유
3. curl 테스트 결과 (실제 차단/통과 확인)
4. 매칭 우선순위와 wildcardOrder 중요성
5. 결론 및 실무 팁

1. 전체 쿠키 정책 구성 요약

Cookie에 대해 적용할 수 있는 Violation은 아래와 같습니다.

• Expired timetamp – HTTP 쿠키의 타임스탬프가 만료된 것이 아닌지 확인합니다.
• Illegal cookie length – 쿠키의 헤더가 명시된 허용 길이를 초과하는지 확인합니다.
• Cookie not RFC-compliant – 이 위반은 HTTP 쿠키에 다음 구성 요소 중 하나 이상이 포함된 경우 발생합니다. 다음 구성 요소는 여기를 클릭하여 확인하세요.
• Modified domain cookie(s) – 요청 내 웹 애플리케이션 쿠키가 변조되지 않았는지 확인하고, 정책에 정의된 웹 애플리케이션 쿠키가 포함되어 있는지 확인합니다.

아래와 같이 Cookie Name별 정책을 생성합니다.

• Cookie Type
  • Explicit – 정확한 쿠키 이름만 적용합니다.
  • Wildcard – 와일드카드 문자가 와일드카드로 해석됩니다.
• Cooke Name – 적용할 쿠키 이름을 정의합니다.
• Enforcement Type
  • Allow – 보안 정책에 따라 클라이언트가 이 쿠키를 변경할 수 있음을 지정합니다. 시스템은 이 쿠키를 무시합니다.
  • Enforce – 보안 정책에 따라 클라이언트가 이 쿠키를 변경할 수 없음을 지정합니다.\
• Enable attack signatures – 이 옵션을 체크하면 해당 쿠키에서 attack signature 및 threat campaign을 감지하고, 보안 정책 설정을 재정의(Attack Signature Overrides)할 수 있습니다.
• Mask value in logs – F5 WAF for NGINX 로그에서 쿠키 값이 (*)로 표시됩니다.
• Attack Signature Overrides – Signature를 선택하여 해당 쿠키에 대한 signatures를 재정의합니다.

예시로 다음과 같이 쿠키를 설정합니다.

아래는 적용된 쿠키들의 정책 구성 배열입니다.

        "cookies": [
            {
                "name": "*",
                "accessibleOnlyThroughTheHttpProtocol": false,
                "attackSignaturesCheck": true,
                "decodeValueAsBase64": "disabled",
                "enforcementType": "enforce",
                "insertSameSiteAttribute": "none",
                "maskValueInLogs": false,
                "securedOverHttpsConnection": false,
                "signatureOverrides": [],
                "type": "wildcard",
                "wildcardOrder": 99
            },
            {
                "name": "session_id",
                "attackSignaturesCheck": true,
                "enforcementType": "enforce",
                "maskValueInLogs": true,
                "signatureOverrides": [],
                "type": "explicit"
            },
            {
                "name": "auth_token",
                "attackSignaturesCheck": true,
                "enforcementType": "allow",
                "maskValueInLogs": true,
                "signatureOverrides": [],
                "type": "explicit"
            },
            {
                "name": "tracking_*",
                "attackSignaturesCheck": false,
                "enforcementType": "allow",
                "maskValueInLogs": false,
                "signatureOverrides": [],
                "type": "wildcard",
                "wildcardOrder": 2
            }
        ],

각 쿠키의 주요 속성과 역할은 아래 표와 같습니다.

2. 각 쿠키별 정책 작동 방식 및 구성 이유

session_id — explicit / enforce

구성 이유
세션 쿠키는 탈취 시 계정 전체가 위험해지는 가장 민감한 쿠키입니다. enforce로 설정해 WAF가 값의 무결성을 검증하고, 변조나 공격 시그니처 탐지 시 즉시 차단합니다.

작동 방식

• 요청 수신 → session_id 쿠키 존재
• 값이 변조됨 → VIOL_COOKIE_MODIFIED → 차단
• 공격 시그니처 탐지 → attackSignaturesCheck → 차단
• 값이 비정상 길이 → VIOL_COOKIE_LENGTH → 차단
• 정상 → 통과 (로그에 값 마스킹)

auth_token — explicit / allow

구성 이유
인증 토큰(JWT 등)은 복잡한 포맷을 가지므로 WAF의 무결성 검증이 오탐을 일으킬 수 있습니다. allow로 차단은 하지 않되, attackSignaturesCheck: true로 공격 패턴은 탐지(알람)하고, 로그에서 값은 마스킹합니다.

작동 방식

• 요청 수신 → auth_token 쿠키 존재
• 공격 시그니처 탐지 → alarm만 발생, 차단 안 함
• 값이 변조됨 → alarm만 발생, 차단 안 함
• 정상/비정상 모두 → 통과 (로그에 값 마스킹)

tracking_* — wildcard (order 2) / allow

구성 이유
광고/분석용 트래킹 쿠키는 외부 마케팅 솔루션이 임의 값을 넣는 경우가 많아 시그니처 검사 시 오탐 가능성이 높습니다. attackSignaturesCheck: false로 검사 자체를 제외하고, 마케팅 분석을 위해 로그에 값도 노출합니다.

작동 방식

• 요청 수신 → tracking_로 시작하는 쿠키 존재
• 시그니처 검사 없음 → 무조건 통과 (로그에 값 그대로 기록)

* (미등록 쿠키) — wildcard (order 99) / enforce

구성 이유
위 4개 규칙에서 매칭되지 않은 모든 미등록 쿠키에 대한 기본 방어선입니다. wildcardOrder: 99로 가장 마지막에 평가되며, 알 수 없는 쿠키는 WAF가 무결성을 강제 검증합니다.

작동 방식

• 요청 수신 → 위 4개 규칙 모두 미매칭
• 변조/만료/비정상 감지 → 차단
• 정상 → 통과 (로그에 값 노출)

3. curl 테스트 결과 (실제 차단/통과 확인)

session_id

# VIOL_COOKIE_MODIFIED 차단 (HMAC 서명 없는 임의값)
curl -k http://localhost -H "Cookie: session_id=abc123validvalue"
# VIOL_COOKIE_LENGTH 차단
curl -k http://localhost -H "Cookie: session_id=$(python3 -c "print('A'*5000)")"
# VIOL_COOKIE_MODIFIED + metachar 차단
curl -k http://localhost -H "Cookie: session_id=abc' OR '1'='1"

auth_token

# 통과
curl -k http://localhost -H "Cookie: auth_token=eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyMSJ9.signature"
# 통과
curl -k http://localhost -H "Cookie: auth_token="

tracking_*

# 통과
curl -k http://localhost -H "Cookie: tracking_ga=GA1.2.1234567890.1234567890"
# 통과
curl -k http://localhost -H "Cookie: tracking_fbp=fb.1.1234567890.987654321"

* (미등록 쿠키)

# 차단
curl -k http://localhost -H "Cookie: unknown_cookie=normalvalue"
# 차단
curl -k http://localhost -H "Cookie: unknown_cookie='; DROP TABLE users;--"

4. 매칭 우선순위와 wildcardOrder 중요성

WAF for NGINX는 쿠키를 아래 순서로 매칭합니다:

1. explicit (정확한 이름) → session_id, auth_token
2. wildcard (낮은 wildcardOrder 숫자부터) → allow-*, tracking_*
3. wildcard (높은 숫자) → * (order 99)

wildcardOrder를 명시하지 않거나 잘못 설정하면 의도하지 않은 규칙이 먼저 매칭되어 차단될 수 있으므로, 항상 구체적 → 일반적 순으로 숫자를 부여하세요.

5. 결론

WAF for NGINX의 쿠키 정책은 이름별로 enforce / allow를 자유롭게 설정할 수 있어 매우 유연합니다. 민감한 세션·인증 쿠키는 enforce + 강력한 보안 속성으로 보호하고, 트래킹/파트너 쿠키는 allow + 검사 제외로 운영하는 것이 실무에서 가장 효과적입니다.

• session_id 같은 핵심 쿠키는 반드시 enforce + HMAC 검증 적용
• tracking_* 쿠키는 attackSignaturesCheck: false + maskValueInLogs: false
• wildcardOrder를 반드시 명시하여 매칭 순서 보장
• signature-sets에서 XSS 등 시그니처를 삭제한 경우, allow 쿠키에서 공격 패턴이 통과될 수 있으니 주의
• 프로덕션 적용 전 curl + 로그 분석으로 충분히 검증

WAF for NGINX의 쿠키 정책에 대해 더 궁금하시거나 실제 환경 적용이 필요하시면 언제든 문의 주세요!