Listen to this Post
Introduction
Email verification is a critical step in user registration, designed to ensure that the email address provided is valid and belongs to the person signing up. However, improper implementation can allow attackers to bypass this check by directly accessing post‑verification endpoints, leading to unauthorized account creation, spam, or even account takeover. This article explores a real‑world email verification bypass discovered during a bug bounty hunt, providing a technical deep dive into the vulnerability, exploitation steps, and effective countermeasures.
Learning Objectives
- Understand the typical flow of email verification and how direct endpoint access can subvert it.
- Learn manual and automated techniques to discover and exploit email verification bypass vulnerabilities.
- Implement robust server‑side controls to prevent such bypasses and secure user registration flows.
You Should Know
1. Understanding Email Verification Flows
In a standard account creation process, the user submits a registration form with their email and password. The application then:
– Creates a pending user record with a `verified` flag set to false.
– Sends a verification email containing a unique, time‑limited token.
– The user clicks the link, which hits a verification endpoint (e.g., /verify?token=xyz). The server validates the token and sets verified = true.
– Finally, the user is redirected to a post‑registration page (e.g., `/welcome` or /dashboard).
The flaw: If the application does not properly check the `verified` status on subsequent requests, an attacker can directly navigate to `/welcome` after registration, bypassing the email verification entirely.
2. Reconnaissance and Endpoint Discovery
Before exploiting, you need to map the application’s endpoints. Common techniques include:
Using browser Developer Tools
- Open the Network tab during a normal registration.
- Look for XHR/fetch requests after form submission. Note the endpoints like
/api/register,/api/verify,/api/dashboard.
Directory/File Brute‑forcing
Use tools like `gobuster` (Linux) or `dirb` to discover hidden endpoints:
gobuster dir -u https://target.com -w /usr/share/wordlists/dirb/common.txt -x php,html,js
Manual inspection
- Check JavaScript files for hardcoded routes.
- Use `curl` to probe common paths:
curl -I https://target.com/verify curl -I https://target.com/complete-registration
Windows alternative: Use `curl` in PowerShell or install `dirb` via WSL.
- Exploiting Direct Endpoint Access – Step by Step
Once you suspect a verification bypass, follow these steps: -
Register a new account with a disposable email. Intercept the request using Burp Suite.
- After submission, note the response. The server might redirect to a “verify your email” page, but the actual endpoint for the next step might be accessible.
- Identify the post‑verification URL – often found in the HTML source or by monitoring network traffic. For example, after registration the app might load `/account/pending` but also make a request to
/api/user/status. - Directly access the protected endpoint using `curl` or Burp Repeater:
curl -b cookies.txt https://target.com/dashboard
If the dashboard loads without the email being verified, the bypass exists.
- Confirm the bypass by checking if any privileged actions (like posting content) are possible. Also try accessing other endpoints like
/settings,/profile/edit.
Burp Suite method:
- Capture the registration request and send it to Repeater.
- Modify the request path to the suspected post‑verification endpoint (e.g.,
POST /api/complete-registration). - If the server responds with a 200 OK and grants access, the vulnerability is confirmed.
4. Advanced Exploitation: Chaining with IDOR
Often, the post‑verification endpoint accepts a user identifier. If the application uses predictable IDs (e.g., sequential), you can combine the bypass with Insecure Direct Object References (IDOR) to take over other accounts.
Example: After bypassing verification for your own account, you might notice the endpoint `/api/user/1234/confirm` uses your user ID. Try changing it to another user’s ID (e.g., /api/user/1235/confirm) – if the server doesn’t verify ownership, you could verify someone else’s email without their interaction.
Testing with curl:
curl -X POST -b cookies.txt https://target.com/api/user/1235/confirm
5. Mitigation Techniques
Developers can prevent email verification bypasses by:
- Server‑side status checks: Every request to protected endpoints must verify the `email_verified` flag from the database, not from a client‑side variable.
- Use of state parameters: Include a cryptographically random token in the registration session that must be present when accessing post‑verification pages.
- Enforce email verification before sensitive actions: Do not allow any functionality (even profile viewing) until the email is verified.
- Implement CSRF tokens on all state‑changing endpoints to prevent simple direct requests.
- Rate limiting and logging: Monitor repeated attempts to access verification endpoints without a valid token.
Code example (vulnerable vs. fixed) – vulnerable PHP:
// vulnerable: no check on dashboard
if ($_SESSION['user_id']) {
echo "Welcome to dashboard";
}
Fixed version:
$user = getUserFromDB($_SESSION['user_id']);
if ($user && $user['email_verified']) {
echo "Welcome to dashboard";
} else {
header('Location: /verify-email');
exit;
}
6. Hands‑on Lab: Setting Up a Test Environment
To practice, create a simple vulnerable application using Node.js/Express or Python/Flask.
Basic vulnerable app (Node.js):
// registration endpoint
app.post('/register', (req, res) => {
const user = { email: req.body.email, verified: false };
db.save(user);
req.session.userId = user.id;
res.redirect('/dashboard'); // immediately redirects without verification!
});
// dashboard – no verification check
app.get('/dashboard', (req, res) => {
if (req.session.userId) {
res.send('Dashboard – you bypassed email verification!');
} else res.redirect('/login');
});
Exploit: Just register and you’re in.
Fixed version:
app.post('/register', (req, res) => {
const user = { email: req.body.email, verified: false };
db.save(user);
// send email with token, do NOT set session yet
res.send('Please verify your email');
});
app.get('/dashboard', (req, res) => {
const user = db.find(req.session.userId);
if (user && user.verified) {
res.send('Dashboard');
} else {
res.redirect('/verify-email');
}
});
7. Real‑World Impact and Bug Bounty Tips
- Impact: Unverified accounts can be used to spam, create fake profiles, or bypass age restrictions. In some cases, attackers can access premium features without payment.
- Reporting: Clearly describe the steps, include screenshots, and demonstrate the security impact (e.g., ability to post content without verification).
- Write‑ups: Many bug bounty hunters share their findings on platforms like Medium – studying them helps you understand patterns. Always follow responsible disclosure.
What Undercode Say
- Key Takeaway 1: Never trust client‑side verification; always enforce email confirmation on the server before granting access to protected resources.
- Key Takeaway 2: Manual testing of business logic flaws (like direct endpoint access) often uncovers critical vulnerabilities that automated scanners miss.
Analysis: This bypass is a classic example of broken access control (OWASP A1) and highlights how developers sometimes overlook simple server‑side checks. The ease of exploitation makes it a favourite among bug bounty hunters, but it also poses a real threat to any web application that handles user registrations. By understanding the underlying flow and applying the mitigation techniques outlined above, organizations can close this gap and protect their users from account‑related fraud.
Prediction
As more applications move toward API‑driven architectures, the number of endpoints increases, raising the likelihood of such direct‑access flaws. Future attacks may combine email verification bypass with automated account creation bots, leading to large‑scale spam campaigns. However, we also expect security tools to evolve, incorporating business‑logic checks that simulate complete user journeys. The onus remains on developers to adopt secure coding practices and conduct thorough penetration testing, especially during registration and authentication flows.
▶️ Related Video (86% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Https: – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
