Listen to this Post
Introduction:
Modern authentication systems rely heavily on email normalization to ensure consistency, but inconsistent handling of Unicode and Punycode can create a critical authentication bypass. A recent vulnerability discovered in a gaming platform demonstrated how an attacker could exploit a discrepancy between registration and password reset endpoints, submitting a visually similar email containing a Unicode character to trigger a password reset on a victim’s account they never owned.
Learning Objectives:
- Understand how Punycode and Unicode normalization inconsistencies can lead to account takeover.
- Identify discrepancies in how registration and password reset endpoints process email addresses.
- Learn to test for and mitigate Unicode-based normalization flaws in authentication workflows.
You Should Know:
1. The Unicode Normalization Gap
The core vulnerability lies in inconsistent email normalization between two critical functions: user registration and password reset. In the real-world example, the registration endpoint accepted an email containing a Unicode character (e.g., yogi@gmôil.com) as a new, distinct address. However, the password reset endpoint normalized this Unicode string to its ASCII equivalent ([email protected]) before processing. This meant that by creating an account with a Unicode-aliased email, an attacker could subsequently request a password reset for that same string. The system would normalize it to the victim’s legitimate ASCII address and send the reset link to the victim’s inbox. If the victim was not the one who requested the reset, they might ignore the email, while the attacker could use social engineering or wait for the victim to reset their password, effectively locking them out or gaining access.
Step-by-step guide explaining what this does and how to use it.
– Step 1: Identify Inconsistent Endpoints. Map out all authentication-related endpoints, specifically `/register` (or /signup) and `/forgot-password` (or /reset). The goal is to see if they use different normalization functions.
– Step 2: Craft a Unicode Payload. Using a tool like `dnspython` or online Punycode converters, create an email that visually mimics a legitimate address. For example, use a Unicode homoglyph: `admin@gmаil.com` where the ‘a’ is a Cyrillic ‘а’ (U+0430). Or use a Unicode character that normalizes to an ASCII equivalent, such as `user@outløok.com` where ‘ø’ normalizes to ‘o’.
– Step 3: Register with the Unicode Address. Using `cURL` or a tool like Burp Suite, send a registration request with the crafted email. Observe the server’s response. It should succeed, creating a new account.
curl -X POST https://target.com/api/register \
-H "Content-Type: application/json" \
-d '{"email":"yogi@gmôil.com","password":"P@ssw0rd!"}'
– Step 4: Trigger Password Reset. Immediately after, send a password reset request for the same Unicode string to the `/forgot-password` endpoint.
curl -X POST https://target.com/api/forgot-password \
-H "Content-Type: application/json" \
-d '{"email":"yogi@gmôil.com"}'
– Step 5: Observe the Outcome. If the reset endpoint normalizes the email to [email protected], the reset token will be sent to the legitimate victim’s inbox. This confirms the vulnerability. The attacker now has a vector to disrupt or potentially take over the account if the victim resets their password.
2. Exploitation Techniques and Impact Demonstration
Demonstrating impact without relying on an external collaborator is a common challenge. In this scenario, the impact is clear: account takeover. However, to prove it in a bug bounty context, you must demonstrate control over the victim’s account without actually compromising it. The technique involves using a disposable email service or a test domain you control. Register with `[email protected]` where the Unicode character is present, then trigger the reset. Since you own the mailbox, you can complete the reset and demonstrate that the normalized email address—which you do not own—is the one that received the reset link.
Step-by-step guide explaining what this does and how to use it.
– Step 1: Set Up a Controlled Environment. Register a domain you control (e.g., attacker.com). Create two email addresses: `[email protected]` and `victim@аttacker.com` (with a Cyrillic ‘a’).
– Step 2: Execute the Registration-Reset Flow. Register on the target platform using victim@аttacker.com. Then, request a password reset for the same address.
– Step 3: Monitor Your Mailbox. Check the mailbox for `[email protected]` (the ASCII version). If you receive the reset token there, you have successfully demonstrated that the system normalized the email and sent the reset to an account you control that is distinct from the one you registered. This proves the inconsistency without needing a third-party collaborator.
– Step 4: Document the Flow. In your report, include screenshots showing the successful registration with the Unicode email, the reset request, and the receipt of the reset link in the normalized email’s inbox.
3. Code-Level Analysis and Mitigation
To prevent this, developers must enforce a homogenous normalization strategy across all authentication-related functions. The recommended approach is to normalize all email addresses to a single, standard form at the point of input for every request.
Step-by-step guide explaining what this does and how to use it.
– Step 1: Implement Unicode Normalization. In the backend, use libraries to convert email addresses to their canonical form. In Python, the `unicodedata` module can be used.
import unicodedata
import re
def normalize_email(email):
Normalize to NFKC form (compatibility decomposition)
email = unicodedata.normalize('NFKC', email)
Encode to ASCII, ignoring non-ASCII characters or replacing them
email = email.encode('ascii', 'ignore').decode('ascii')
Optionally, convert to lowercase
email = email.lower()
Remove any tags (like +) if not supported
email = re.sub(r'+.?(?=@)', '', email)
return email
– Step 2: Apply Normalization Consistently. Ensure this normalization function is called on every email address as soon as it enters the application, whether from registration, login, or password reset endpoints.
In a Flask route
@app.route('/api/register', methods=['POST'])
def register():
email = request.json.get('email')
normalized_email = normalize_email(email)
Check if normalized_email already exists in the database
Store the normalized version in the DB
...
@app.route('/api/forgot-password', methods=['POST'])
def forgot_password():
email = request.json.get('email')
normalized_email = normalize_email(email)
Look up user by normalized_email and send reset
...
– Step 3: Reject Non-Standard Emails During Registration. Instead of allowing a Unicode email that will be normalized later, consider rejecting emails that contain non-ASCII characters at the point of registration, unless your business logic explicitly requires internationalized email support. This can be done with a simple regex or library check.
4. Testing for Other Unicode Attack Vectors
The Punycode vulnerability extends beyond just email normalization. The same principle applies to any field where user input is normalized, such as usernames, domain names in SSO configurations, or redirect URIs in OAuth flows.
Step-by-step guide explaining what this does and how to use it.
– Step 1: Test Username Normalization. Attempt to register a username with a Unicode homoglyph (e.g., admìn) and then try to log in with the ASCII version (admin). If the system normalizes one but not the other, it could lead to account confusion or takeover.
– Step 2: Test OAuth/SSO Flow. If the application supports single sign-on, try to initiate an OAuth flow with a Unicode email. Intercept the request and modify the `email` claim in the ID token to include a Unicode character. Observe if the application normalizes the email before linking it to an existing account.
– Step 3: Use Automated Tools. Integrate a Unicode fuzzing tool into your CI/CD pipeline. Tools like `wfuzz` with a Unicode payload list can automate testing for normalization issues across all input fields.
wfuzz -c -z file,unicode_emails.txt -d "email=FUZZ" https://target.com/api/register
5. Advanced Exploitation: Chaining with Race Conditions
When combined with race conditions, this vulnerability becomes even more critical. If the registration and reset endpoints are not properly synchronized, an attacker could rapidly register a Unicode account and trigger a reset, potentially intercepting the token before the legitimate user is aware.
Step-by-step guide explaining what this does and how to use it.
– Step 1: Automate the Flow. Write a script that sends a registration request for a Unicode email and immediately sends a password reset request for the same address. Use concurrency to minimize the time gap.
import threading
import requests
def register(email):
requests.post('https://target.com/register', data={'email': email})
def reset(email):
requests.post('https://target.com/reset', data={'email': email})
email = 'yogi@gmôil.com'
t1 = threading.Thread(target=register, args=(email,))
t2 = threading.Thread(target=reset, args=(email,))
t1.start()
t2.start()
– Step 2: Exploit the Race. By sending both requests nearly simultaneously, you might cause the system to generate and send a reset token for an account that is still being created. In some implementations, this can lead to the token being sent to an attacker-controlled mailbox or being disclosed in an error message.
What Undercode Say:
- Inconsistent normalization is a critical design flaw. Treating user input differently across authentication endpoints creates a direct path to account takeover. Security must be built on uniformity, not convenience.
- Testing for Unicode vulnerabilities is now a standard requirement. As applications become more global, supporting internationalized email addresses (EAI) is necessary, but it must be done with a unified security strategy. Developers must normalize at the edge, not in the database.
The Punycode authentication vulnerability serves as a stark reminder that subtle discrepancies in input handling can lead to severe consequences. This isn’t a complex injection or a cryptographic failure; it’s a logic flaw stemming from a lack of consistency. As more applications adopt AI-driven input sanitization and globalized user bases, the attack surface for Unicode-based normalization attacks will expand. Security teams must shift left, integrating tests for normalization inconsistencies into their CI/CD pipelines and treating authentication flows as a single, atomic unit of security design.
Prediction:
As the adoption of Internationalized Domain Names (IDNs) and email addresses increases, the frequency of normalization-based authentication bypasses will rise. Attackers will increasingly automate the discovery of normalization inconsistencies across registration, login, and password reset flows. Future frameworks will likely enforce mandatory, configurable normalization policies as a core security feature, while AI-driven code analysis tools will begin to automatically flag these discrepancies as high-severity vulnerabilities during the development phase.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Yogesh Ravichandran – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
