Bypassing Email Verification with Simple Parameter Tampering

Introduction

During a recent security assessment on a major travel booking platform, I decided to test their account registration and identity verification flows. Email verification is a fundamental security control — it exists to prove that a user actually owns the email address they are using to sign up. However, I discovered a critical business logic flaw that completely broke this trust model. By simply manipulating the data sent between my browser and the server, I was able to successfully verify an account registered under someone else's email address without ever needing access to their inbox.

The Reconnaissance / Observation

I started by mapping out the standard account creation process. On this platform, a user could sign up using a traditional password-based flow. Once registered, the account was created but flagged as "unverified" until the user clicked a "Verify" button, which would send a One-Time Password (OTP) to their email.

While monitoring the background traffic in Burp Suite, I clicked the "Verify" button and closely examined the HTTP request. I noticed something that always catches my attention: the request explicitly included my email address as a parameter.

This immediately sparked a classic hacker question: Why is my browser telling the server where to send the OTP? Since I am already logged into my account, shouldn't the server just look up my registered email in its own database? What happens if I change that email parameter to something else?

The Vulnerability

This flaw is a textbook example of Parameter Tampering resulting from a Missing Server-Side Binding.

In a secure architecture, the verification process should be strictly tied to the account's existing state on the backend. When a user requests an OTP, the server should say, "I know who is logged in, I will send the code to the email saved in their profile."

Instead, this platform's backend blindly trusted the client. It essentially said, "I will send an OTP to whatever email address you type in this request, and if you provide the correct OTP for that specific email, I will mark your current account as verified." The system completely failed to bind the verification challenge to the original email identity.

The Exploitation

Exploiting this vulnerability was simple and required no advanced tools other than an interception proxy. Here is exactly how I carried out the attack:

1. The Setup: I went to the registration page and created a new account using an email address I did not own (the victim's email). The account was successfully created but sat in an "unverified" state.

2. Trigger the Challenge: While logged into this unverified account, I clicked the "Verify" button to initiate the email confirmation process.

3. The Swap: Before the request could leave my computer, I intercepted it using Burp Suite. In the request body, I found the email parameter pointing to the victim's email address. I deleted it and typed in my own attacker-controlled email address.

4. The Intercept: I forwarded the modified request. Because the server trusted my input, it generated the OTP and emailed it directly to my attacker inbox, completely bypassing the victim.

5. The Confirmation: I retrieved the 6-digit OTP from my inbox and entered it into the verification form on the website.

6. The Second Swap: I intercepted the final submission request. Just like before, I changed the email parameter to my attacker email so it would perfectly match the OTP the server had just generated.

7. The Result: I forwarded the final request. The server validated the OTP, saw that it matched the email in the request, and returned a success message. The account — which was registered under the victim's email — was now officially marked as "Verified" in the system, even though I never touched the victim's inbox.

The Impact

By bypassing this core verification mechanism, an attacker can hijack the perceived identity of anyone on the platform. They can register accounts using the email addresses of high-profile targets, corporate executives, or rival businesses, and gain a "Verified" badge. This can lead to severe reputational damage, facilitate highly convincing phishing campaigns originating from "trusted" internal platform accounts, and completely undermine the integrity of the platform's user database.