Comment on page
Python - Client Side Restriction Bypass - Harder
$ sudo docker pull blabla1337/owasp-skf-lab:client-side-restriction-bypass-2
$ sudo docker run -ti -p 127.0.0.1:5000:5000 blabla1337/owasp-skf-lab:client-side-restriction-bypass-2
Now that the app is running let's go hacking!
As we have done with previous labs, be sure to start Burp Suite so you can play along! Testing becomes so much easier if you use Burp's built-in Chrome web browser (tab Proxy > tab Intercept > button Open Browser).
For now, let's try user "admin" and password "admin". Which does let us inside!
We're told that the "admin" user really likes the color blue and that they enjoy feasting on apple pie. That's great news! And since we're logged in as the user "admin", we can even update our favorite color!
After submitting the form with a different color, the output has changed.
Let's take a look at Burp Suite's proxy history, to see what's happening in the background.
Burp shows us that a POST request was made to http://0.0.0.0:5000/updatecolor. The form was submitted with one key:value pair, being "color=Green".
Looking into the HTTP requests in Burp, there appear to be no hidden form values that would allow us to change admin's favorite food. But let's try something! Maybe the web app is trying to hide some things in plain sight by simply not including them in the user interface. We can make a few guesses about what to try, no?
We could just edit HTTP requests in Burp, making educated guesses.
If you right-click the POST request in Burp's proxy history, you can select "Send to Repeater". This will light up the Repeater tab in orange, showing that something new appeared. Over there, we can edit the request before submitting it.
Let's change the called URL to http://0.0.0.0:5000/updatefood and let's change the form key to "food". Then if we click the "Send" button, maybe we'll get lucky!
Alternatively, let's take a closer look at that front-end code! By right-clicking the form in our browser (or ctrl+shift+i) and choosing "Inspect" we can investigate the HTML in question.
What's this?!
The developer left us the clues right there in the HTML? And we manually did the hard work? No fair! Well, might as well use the form then!
If you right-click the commented text and choose "Edit as HTML" we can just remove the
<!-- and --> comment markers. And presto, there's our other form which will let us change the favorite food as well.
If the developer wanted to prevent us from updating the food, they should have either disabled the endpoint temporarily or added an additional security check. In its current state, it's just "security through obscurity. "Hiding" functionality by not turning it on, by not using it and so on does nothing to secure your applications.