The Hidden Threat in Plain Sight: How a Simple ‘Resend OTP’ Button Can Cripple Your Systems

Introduction:

In the intricate world of application security, the most significant vulnerabilities often lurk within the most mundane functionalities. A recent discovery involving a government portal’s account activation flow underscores this reality, demonstrating how a poorly implemented “Resend OTP” feature can be weaponized to launch denial-of-service attacks and drain backend resources. This incident highlights a critical oversight in application design: the failure to implement robust rate-limiting controls on seemingly harmless user interactions.

Learning Objectives:

• Understand the security risks associated with uncontrolled OTP resend functionalities.
• Learn to identify and test for missing rate-limiting mechanisms in web applications.
• Implement effective mitigation strategies using code-level fixes and web server configurations.

You Should Know:

1. Identifying the Vulnerability with Burp Suite Intruder

The first step is to confirm the absence of rate limiting. While manual clicking is possible, automated tools are far more efficient for testing.

Step-by-step guide:

1. Intercept the HTTP POST request sent when clicking the “Resend OTP” button using a proxy tool like Burp Suite.
2. Send the intercepted request to the Burp Intruder tool.
3. In the Intruder tab, ensure the attack type is set to “Sniper.”
4. Clear any existing payload positions and highlight the value of the session token or any unique identifier. Click “Add §” to set it as a payload position. (Note: The attack may work even without a payload position if the endpoint lacks session tracking).
5. Go to the “Payloads” tab. For a simple test, select the “Payload set” as 1 and “Payload type” as “Simple list.” You can add a single dummy word like “test” since the payload count, not content, matters for flooding.
6. Start the attack. The Intruder will rapidly send hundreds or thousands of requests to the target endpoint.
7. Observe the results. If all requests return HTTP 200 (or similar success codes) and you receive a flood of OTPs, the vulnerability is confirmed.

2. Mitigation: Implementing Application-Level Rate Limiting in Node.js

The most robust solution is to implement rate limiting within the application code itself, tracking attempts per user session or phone number.

Verified Code Snippet (Node.js with Express):

const rateLimit = require('express-rate-limit');

// Define a rate limiter for OTP resends
const otpResendLimiter = rateLimit({
windowMs: 15  60  1000, // 15 minutes
max: 3, // Limit each session to 3 OTP requests per windowMs
message: {
error: 'Too many OTP requests, please try again after 15 minutes.'
},
keyGenerator: (req) => {
// Use the session ID OR phone number as the key
return req.session.id || req.body.phoneNumber;
}
});

// Apply the limiter to the resend OTP route
app.post('/resend-otp', otpResendLimiter, (req, res) => {
// Your existing OTP resend logic here
res.status(200).json({ message: 'OTP sent successfully.' });
});

Step-by-step guide:

This code uses the `express-rate-limit` package. The limiter is configured with a 15-minute window (windowMs) and a maximum of 3 requests (max). The `keyGenerator` function determines what to limit by—either the user’s session ID or the phone number submitted in the request. Any requests exceeding the limit are blocked, and a clear error message is returned.

3. Mitigation: Web Server Rate Limiting with Nginx

For a defense-in-depth approach, rate limiting can also be enforced at the web server level, protecting even parts of the application that might lack internal controls.

Verified Nginx Configuration Snippet:

http {
 Define a rate limit zone named 'otp' with a 10 request per minute limit
limit_req_zone $binary_remote_addr zone=otp:10m rate=10r/m;

server {
listen 80;
server_name yourportal.com;

Apply the rate limit to the resend OTP endpoint
location /api/resend-otp {
limit_req zone=otp burst=5 nodelay;
proxy_pass http://your_backend_app;
}
}
}

Step-by-step guide:

This Nginx configuration creates a shared memory zone (otp) to track request rates based on the client’s IP address ($binary_remote_addr). The zone allows 10 requests per minute (rate=10r/m). The `limit_req` directive inside the `location` block for the OTP endpoint applies this rule. The `burst=5` parameter allows a short queue of up to 5 excess requests, which are processed with a delay, while `nodelay` ensures requests over the burst limit are immediately rejected.

4. Mitigation: Advanced Tracking with Redis

For distributed applications, using an in-memory data store like Redis is essential for consistent rate limiting across multiple servers.

Verified Code Snippet (Python/Flask with Redis):

import redis
from flask import Flask, request, jsonify
import time

app = Flask(<strong>name</strong>)
redis_client = redis.Redis(host='localhost', port=6379, db=0)

@app.route('/resend-otp', methods=['POST'])
def resend_otp():
phone_number = request.json.get('phone_number')
key = f"otp_attempts:{phone_number}"

Get current attempts or set to 0 if key doesn't exist
attempts = redis_client.get(key)
if attempts and int(attempts) >= 3:  Limit of 3 attempts
return jsonify({"error": "Rate limit exceeded. Try again later."}), 429

Increment the attempts counter, with a 15-minute expiration
pipe = redis_client.pipeline()
pipe.incr(key)
pipe.expire(key, 900)  15 minutes in seconds
pipe.execute()

... Logic to send OTP ...
return jsonify({"message": "OTP sent successfully."})

if <strong>name</strong> == '<strong>main</strong>':
app.run()

Step-by-step guide:

This Flask application uses a Redis database to track OTP attempts per phone number. The key is structured as otp_attempts:

</code>. When a request is made, the code checks the current attempt count. If it's 3 or more, a 429 error is returned. If not, it increments the counter and sets an expiration time of 900 seconds (15 minutes) on the key, after which the counter resets automatically.

<h2 style="color: yellow;">5. Exploitation Proof-of-Concept with cURL</h2>

Understanding how an attacker would abuse this flaw is crucial for defense. A simple bash loop with cURL can simulate the attack.

<h2 style="color: yellow;">Verified Bash Script Snippet:</h2>

[bash]
!/bin/bash
 Simple POC script for OTP flooding
URL="https://vulnerable-portal.com/api/resend-otp"
SESSION_COOKIE="session_cookie_value_here"

for i in {1..1000}; do
echo "Sending request $i"
curl -s -X POST "$URL" -b "session=$SESSION_COOKIE" > /dev/null
done
echo "OTP flood attack complete."