Business Logic Vulnerability (Labs: Portswigger Academy)

Labs from PortSwigger Academy

Lab 1: Excessive trust in client-side controls

POST /cart

productId=1&redir=PRODUCT&quantity=1&price=100

price value can be easily edited.

Lab 2: High-level logic vulnerability

POST /cart

productId=2&redir=PRODUCT&quantity=5

we can set the quantity value to negative
first, add negative number of items in cart (total cost will be in negative). If we try to buy, we get error because of -ve total cost.

to change -ve total to +ve, add different products until the total becomes +ve

our order should be something like this

|Name|Price|Quantity||
Lightweight "l33t" Leather Jacket --> $1337.00 |1|
Portable Hat --> $43.63  | -30|
Total: $28.10

Lab 3: Inconsistent security controls

change email of new account to @dontwannacry.com
this gives us access to Admin Panel /admin

Lab 4: Flawed enforcement of business rules

We have 2 Coupon to apply at checkout.
If we try to use a coupon back to back it says Coupon Already Used.
But, if we use coupon alternatively, we can use them back to back

Lab 5: Low-level logic flaw

POST /cart
productId=1&redir=PRODUCT&quantity=1

we keep up increasing the quantity interatively, in one point the total cost reaches -ve
because The price has exceeded the maximum value permitted for an integer in the back-end programming language (2,147,483,647). As a result, the value has looped back around to the minimum possible value (-2,147,483,648)

then the total value starts moving towards +ve
we need to stop near our goal (eg; if we have 100$ credit, we stop as 0<total<100)

Lab 6: Inconsistent handling of exceptional input

Admin interface is availabe for @dontwannacry.com

during register is we set the email to very lengthy characther then the webapp removes the portion after certain character.
meaning,
if we set email to ABCDEFGHI.....JKL[e-mail]
it removes the later part and sets the email as ABCDEFGHI.....JKLMNOPQRSTUV [255 char only]


therefore, during register if we set the email to 
[e-mail]

webapp will remove the portion and final email will be
[e-mail]

Hence, we will get access to Admin Panel

Lab 7: Weak isolation on dual-use endpoint

password reset reques

POST /my-account/change-password

username=wiener&current-password=peter&new-password-1=sushil&new-password-2=sushil

we can change the username to administrator and totally remove the current-password section
hence reset password of any user

Lab 8: Insufficient workflow validation

This lab makes flawed assumptions about the sequence of events in the purchasing workflow. To solve the lab, exploit this flaw to buy a "Lightweight l33t leather jacket".

Once we place an order, there are two requests.
POST /cart/checkout  --> Checks the balance and deducts the amount from balance

GET /cart/order-confirmation?order-confirmation=true  --> confirms the order

we can directly use the GET request to confirm order. --> No balance check and deduction, direct order confirmation

Lab 9: Authentication bypass via flawed state machine

This lab makes flawed assumptions about the sequence of events in the login process. To solve the lab, exploit this flaw to bypass the lab's authentication, access the admin interface, and delete the user carlos.

There exist three requests during login process.

POST /login

username=wiener&password=peter

GET /role-selector

POST /role-selector
role=user

after 1st POST /login request
we drop the GET /role-selector request and move to home page.
This bypasses the role selection step and gives defualt administrator role

Lab 10: Infinite money logic flaw

This lab has a logic flaw in its purchasing workflow. To solve the lab, exploit this flaw to buy a "Lightweight l33t leather jacket".

we have SIGNUP30 coupon which gives 30% off.
we buy $10 Giftcard at 7$ using this coupon. PROFIT = 3% 
we repeat this process to get infinite money.


Atomate this process using burp macro