In today’s post we are going to look at two vulnerabilities in Juice Shop. Both of them have to do with manipulating the basket. In the first section we view the basket of a different user. In the second section we add a product to the basket of a different user.
Categories: Cross Site Request Forgery and HTTP Parameter Pollution.
Vulnerability: by editing parameters in the Session Storage and POST requests you can see and change things you shouldn’t be able to see or change.
View the basket of a different user
For this walk through I will use Firefox.
First, we log in and go to the basket. Use Inspect Element on the page and go to Storage. Click on Session Storage. I logged in as admin here. Admin has a basket ID (bid) of 1. The basket is currently empty.
Now we change the bid to 2 and reload the page.
Now we see that there is a product in the basket. This is the basket of a user with bid 2 (jim@juice-sh.op).
Solution
It’s not possible to prevent people from editing and resending POST requests. We can only solve this by changing how the application handles POST requests that come in. In this case we can check if the BasketID belongs to the ID of the currently logged in user. The current user needs to be the owner of the BasketID in the request. If they belong together, such as the Admin account and bid 1, you can see the basket. Otherwise the application should reject the request.
Add a product to the basket of another user
In this example we are Admin again, with a bid of 1. However it doesn’t matter which account you use. Use Inspect Element and go to Network. Add something to your basket, it doesn’t matter what. You will now see a POST request appear in the Network tab.
Right-click on Edit and Resend.
Now we only need to change the Request Body. Change the ProductId to 6 (banana juice) and paste the BasketId of the target after your own BasketId.
Click on Send. We can now check with the previous technique if we were successful.
We can see there is now a banana juice in the basket with bid 2, so it worked!
Solution
The name of the second vulnerability we discussed is HTTP Parameter Pollution. Because of this vulnerability, it’s possible to manipulate a request by entering multiple parameters (bid 1 and bid 2) where only 1 is expected. This makes the application do something that it shouldn’t do – in this case adding a product to another user’s basket.
The main solution for this problem is to use proper input validation. We can check and filter the user input and only accept it if it’s the type that we expect. It is useful to review each request in the application that requires user input and see if there’s a way to make it more secure. We could change the above request in such a way that multiple values for a parameter will make the request invalid.
Sources
- https://serverfault.com/questions/557002/how-do-i-block-malicious-http-request
- https://stackoverflow.com/questions/38400059/stop-malicious-post-requests
- https://stackoverflow.com/questions/48326764/malicious-http-post-requests
- https://serverfault.com/questions/952712/htaccess-rule-to-protect-against-malicious-post-requests-to-wordpress-index-php
- https://owasp.org/www-community/attacks/csrf
- https://bkimminich.gitbooks.io/pwning-owasp-juice-shop/content/appendix/solutions.html
- https://securityintelligence.com/posts/how-to-prevent-http-parameter-pollution/