39:51This recording is not available yet.
Unicode Vulnerabilities That Could Byͥte You
Download resourcesAbout this session
Philippe Arteau, security researcher at GoSecure, presents five classes of Unicode-related vulnerabilities after a primer on code pages, code points and UTF-8 versus UTF-16. First, normalization: compatibility-mode NFKC folds characters such as the fullwidth solidus or circled letters into ASCII, which produced the HostSplit open-redirect bug in OAuth redirect validation that browsers normalized implicitly until mid-2019, and a hostname-verification flaw he found in Oracle JDK and OpenJDK that lets a look-alike certificate pass TLS validation. Second, case mapping: uppercasing the German eszett to SS or lowercasing the Kelvin sign and dotless i to ASCII lets an attacker register a user that later matches admin, as in a Django password-reset issue. Third, filter bypass: UTF-16 or UTF-7 payloads, mid-document encoding switches in XML parsers and SQL Server Latin1 collation converting stored characters into live HTML tags. Fourth, homograph attacks through punycode domains, mitigated by Chrome heuristics and certificate-transparency monitoring. Fifth, silent data loss when encodings are not preserved in backups. He closes by advising validation before any transformation, ASCII-only for security-critical fields and explicit encoding declarations.
The number of Unicode code points has never stopped growing just like its integration in modern technologies. Web applications you have developed or used are likely to support input and output formatted in UTF-8 character encoding.
In this talk, you will learn about the security implications of encoding conversion. Normalizing a UTF-8 string to ASCII only character has numerous potential side effects. The latest research affecting Unicode will be summarized including the HostSplit attack. The HostSplit attack abuses minor characters conversion to trigger open redirect or Server-Side Request Forgery (SSRF). Aside from normalization, uppercase and lowercase transformations can introduce vulnerabilities. Encoding can be used to circumvent security controls such as Web Application Firewalls. Additionally, punycode is the new representation to support domains with special characters outside of ASCII. This representation can be used to create visual confusion to end users.
While some issues were patched in major software, many risks remain or are likely to resurface. Get ready for a complete summary of everything security professionals should know about Unicode!
Key takeaways
- Run every security check (allow-list, hostname match, role comparison) before any normalization or case transformation, never after.
- Restrict security-critical identifiers such as usernames, roles and hostnames to ASCII; keep a separate display column if you need Unicode.
- Audit the libraries and frameworks you rely on for implicit NFKC normalization or ToUpper calls; the OAuth redirect and JDK bugs lived in shared code, not application code.
- When fuzzing filters, try UTF-16 and UTF-7 encodings, XML encoding declarations mid-document and database collation conversions, not just URL and HTML entity encoding.
- Declare the encoding explicitly in code and exports, and once SPF and basic mail hygiene are in place, monitor certificate-transparency logs for punycode look-alikes of your domains.
