Business Logic Vulnerabilities — From Price Tampering to Expert-Level Parser Attacks
Author: Nilanjan Chowdhury
How I completed the entire PortSwigger Business Logic category — Apprentice to Expert
When people think about web vulnerabilities, they think SQL Injection, XSS, CSRF — technical flaws in code. Business logic vulnerabilities are different. They don’t exploit broken code. They exploit broken assumptions.
The developer assumed users would always follow the intended flow. The developer assumed quantities would always be positive. The developer assumed both systems would read the same email the same way.
They were wrong. And that’s where the fun begins.
Here’s my complete walkthrough of the PortSwigger Business Logic category — all 9 labs, Apprentice through Expert — with the purple team breakdown on each one.
🟢 Apprentice Labs
Lab 1 — Excessive Trust in Client-Side Controls
The application let users add items to a cart and sent the price as a parameter in the POST request. The server trusted whatever price the client sent.
Fix? Intercept the request in Burp Suite. Change the price to 1. Checkout. Done.
The lesson here is fundamental — never trust client-supplied input for sensitive values. Price, quantity, discount — these must always be fetched server-side from the database. If it travels through the browser, an attacker can change it.
Lab 2 — High-Level Logic Vulnerability
The application validated that items exist and users are logged in. But it never validated that quantity must be a positive integer.
Sending quantity=-100 drove the cart total into negative values. Add a cheap item to bring the total just above zero, and the jacket is effectively free.
One parameter. No sophisticated tooling. Pure logic failure.
Lab 3 — Inconsistent Security Controls
Registration required an @dontwannacry.com email to gain admin access. But after registering with any email, the email change form had no domain validation at all.
Register normally → verify account → change email to hacker@dontwannacry.com → admin access granted.
The security rule existed in one place but not everywhere it needed to be. Inconsistent enforcement is the same as no enforcement.
Lab 4 — Flawed Enforcement of Business Rules
Two discount coupons: NEWCUST5 and SIGNUP30. The application blocked applying the same coupon consecutively — but not across full order history.
Alternate them repeatedly: NEWCUST5 → SIGNUP30 → NEWCUST5 → SIGNUP30
Each swap reset the “last used” check. Infinite discounts. The jacket price dropped to within store credit.
Business rules must be validated against full transaction history, not just the last action.
🟡 Practitioner Labs
Lab 5 — Inconsistent Handling of Exceptional Input
This one introduced a new class of thinking — what happens when different layers of the application handle the same input differently?
The target: gain access to an admin panel reserved for @dontwannacry.com employees.
The database stored email addresses up to 255 characters. The verification email was sent to the full address. But the stored value was truncated.
So I crafted this:
AAAAAAAAAAAAA...(200+ chars)...AAa@dontwannacry.com
length: over 255 characters. The verification email went to the full address via the exploit server. The database stored only the first 255 characters — which ended in @dontwannacry.com. Admin access granted.
The vulnerability: truncation happened after verification, not before. The stored email no longer matched what was actually verified.
Lab 6 — Weak Isolation on Dual-Use Endpoint
The password change endpoint handled both self-service changes (requiring current-password) and admin-level resets on the same endpoint.
Original request:
username=wiener¤t-password=peter&new-password-1=test&new-password-2=testModified request:
username=administrator&new-password-1=hacked&new-password-2=hacked
Removing current-password and changing username silently fell through to the admin code path. No error. No rejection. Admin password changed.
Authorization must never depend on user-controlled input. One endpoint should never serve two trust levels.
Lab 7 — Insufficient Workflow Validation
The order confirmation endpoint trusted a single GET request as proof that payment had been completed.
GET /cart/order-confirmation?order-confirmed=trueComplete a legitimate cheap order to capture this request. Add the jacket to the cart. Replay the confirmation request. The server fulfilled the order without checking whether payment existed for the current cart.
Every step in a workflow must independently validate its prerequisites. Confirmation without payment verification is just a formality waiting to be bypassed.
Lab 8 — Authentication Bypass via Flawed State Machine
The login flow was designed as a state machine:
POST /login → GET /role-selector → Authorized SessionTurn on Burp Intercept. Log in. Forward POST /login. When GET /role-selector arrives — drop it.
Get Nilanjan Chowdhury’s stories in your inbox
Join Medium for free to get updates from this writer.
Turn off intercept. Browse to /. Admin panel visible. Navigate to /admin. Delete carlos.
The server completed authentication but never assigned a role. Instead of failing safely and invalidating the session, it defaulted to admin behavior.
This is directly analogous to real-world MFA bypass attacks. Drop the MFA step, land in an authenticated session. Applications must always fail safely — missing state must never grant elevated access.
🔴 Expert Lab — The One That Took 5 Hours
Lab 9 — Bypassing Access Controls Using Email Address Parsing Discrepancies
This is where business logic vulnerabilities meet low-level parser behavior.
The application restricted registration to @ginandjuice.shop emails only. No technical bypass was visible. No parameter to tamper. No workflow to skip.
The key was understanding how different components read the same email address.
The application validator read the raw string. The mail server decoded encoded-word syntax before processing.
Encoded-word syntax looks like this:
=?charset?encoding?encoded_text?=UTF-7 specifically encodes special characters:
&AEA- → @
&ACA- → spaceSo I crafted this payload:
=?utf-7?q?attacker&AEA-exploit-XXXX.web-security-academy.net&ACA-?=@ginandjuice.shop
The validator read the raw string and saw ...@ginandjuice.shop — registration allowed.
The mail server decoded the UTF-7 encoding and delivered the verification email to attacker@exploit-XXXX.web-security-academy.net — my exploit server inbox.
I received the verification link. Clicked it. Logged in. Admin panel visible. Carlos deleted.
Same input. Two completely different interpretations. Access control.
This technique is based on real PortSwigger research — “Splitting the Email Atom” by Gareth Heyes — demonstrating how email parser inconsistencies lead to real authentication bypasses in production systems.
🟣 Purple Team Breakdown
The real value of studying business logic vulnerabilities isn’t just knowing how to exploit them. It’s understanding the pattern so you can find AND defend against them.
Attack patterns across all 9 labs:
- Trust client-supplied sensitive values
- Apply security rules inconsistently across the application
- Allow multi-step workflows to be interrupted or replayed
- Let different components interpret the same input differently
Detection strategies:
- Alert on price mismatches between catalog and cart requests
- Monitor for negative quantity values in POST requests
- Flag email changes to privileged domains
- Alert on encoded-word syntax in registration fields
- SIEM rule: admin access from accounts registered within 24 hours
- Monitor for order confirmation requests with no matching payment transaction
- Alert on authenticated sessions where required workflow steps were skipped
Developer fixes:
- Never accept sensitive values from the client — always fetch server-side
- Apply every security rule consistently at every entry point
- Every workflow step must independently validate prerequisites
- Normalize and decode input BEFORE validation — always validate the decoded form
- Use a single parsing library consistently across all components
- When state is ambiguous, always fail to least privilege — never default to elevated access
Key Takeaway
Business logic vulnerabilities are invisible to scanners. No automated tool will find a negative quantity bypass or a UTF-7 parser differential. These require human thinking — understanding what the developer assumed, then testing what happens when that assumption is wrong.
That’s what makes them so dangerous in real applications. And so rewarding to find.
The entire Business Logic category — Apprentice to Expert — complete. 🔒
Follow my cybersecurity journey on
GitHub: https://github.com/CalculusGuy
LinkedIn: https://www.linkedin.com/in/nilanjan-chowdhury-a36787359/
My WEBSITE: https://calculusguy.github.io/nilanjanchowdhury.github.io/
More writeups on Medium: @nilanjan.calculus
#Cybersecurity #Web Security #Ethical Hacking #BugBounty #Penetration Testing
