Normalization Attack

What is a Unicode Normalization Attack?

A Unicode normalization attack exploits the fact that the same logical text can be represented in multiple ways in Unicode, and that different parts of a system may apply different normalization rules (or no normalization at all). If a security check is performed on a non-normalized form but the data is later normalized before use, the normalized form can bypass the check.

How Filter Bypass Works

Consider an application that blocks the string <script> to prevent cross-site scripting. If the filter checks the raw input but the database or rendering layer applies NFKC normalization, an attacker can submit:

＜script＞   (fullwidth less-than U+FF1C, fullwidth greater-than U+FF1E)

The filter sees ＜script＞ — no match for <script>. But NFKC normalization maps U+FF1C to U+003C (<) and U+FF1E to U+003E (>), so the database stores or the browser renders <script>, executing the payload.

Similar bypass potential exists with: - The fi ligature (fi, U+FB01) → normalizes to "fi" under NFKD/NFKC - Superscript digits (¹ U+00B9) → normalize to "1" - Roman numerals (Ⅷ U+2167) → normalize to "VIII" - Compatibility characters like ① (U+2460) → normalizes to "1"

Username Normalization Attacks

Many platforms normalize usernames on registration to prevent homoglyph squatting. If the normalization is applied inconsistently, account takeover becomes possible.

A classic scenario: a platform normalizes usernames to NFC on login but stores them as-entered on registration. An attacker registers admin (with a combining character that disappears after NFC normalization), and the login system considers this equivalent to the existing admin account.

Alternatively, if a platform applies NFKC normalization only at display time, an attacker could register ＡＤＭＩＮs (fullwidth Latin letters) — visually distinct from ADMINS — and gain a username that maps to the same effective identity after normalization.

Case Folding Attacks

Case folding is Unicode's locale-independent method for case-insensitive comparison, defined in CaseFolding.txt. Inconsistent application creates vulnerabilities:

• ß (U+00DF) case-folds to ss — a filter blocking SS might miss ß
• Greek capital sigma Σ (U+03A3) case-folds to σ
• Turkish dotted I — İ (U+0130) lowercases to i\u0307 in Turkish locale but i in others

If a filter applies str.lower() with the wrong locale, certain characters will not be caught.

WAF Bypass Techniques

Web Application Firewalls (WAFs) that operate on raw bytes before normalization are vulnerable to Unicode-based bypass. Attack patterns include:

1. Overlong UTF-8 encoding — now invalid in modern systems, but some parsers historically accepted non-minimal encodings
2. Compatibility decomposition — submitting compatibility characters that decompose to blocked keywords
3. Mixed NFC/NFD input — deliberately submitting NFD-encoded input to a filter expecting NFC

Defense Strategies

1. Normalize at the perimeter — apply NFKC normalization to all user input at the earliest entry point, before any security check
2. Consistent normalization — ensure the same normalization form is applied at input validation, storage, and retrieval
3. Case folding before comparison — use Unicode case folding, not locale-specific toLowerCase()
4. Restrict username characters — consider limiting allowed code points to a safe subset (e.g., IdentifierStatus=Allowed from Unicode TR39)

Quick Facts