From Fries to Flaws : My Journey into Web App Security (Part III)

bugbountytraining.com/FastFoodHackings

Welcome to the third part of our series on BugBountyTraining , In brief, FastFoodHackings is a training website created by Sean (zseano). It helps people learn bug hunting through real-world scenarios. If you missed the first and second parts, be sure to check them out. Let’s continue our journey into uncovering bugs !

(Part I) (Part II)

In the previous part, we focused on the input boxes in the booking form. However, when I was sending the request, something caught my attention. I decided to understand and test it .

So , after forwarding the first request.

The Order_id parameter grabbed my interest. It looks like it might be Base64 encoded, so let's decode it and see what we uncover.

Let’s use CyberChef as our decoding tool, or we can simply right-click it and decode it in Burp Suite.

It seems to be the same order number that appears on the screen after successfully submitting the order.

Let’s send this request to Burp Suite Repeater and experiment with it. It might be vulnerable to some form of Broken Access Control based on my knowledge.

First, let’s send the same request and check if we get the same page.

Intuitively, we should.

As we decoded the order value and discovered that it is 42069, let’s experiment with this number to see if we can access orders belonging to other users.

For example, we can change it from 42069 to 42066 and observe what happens.

But here’s the trick: we need to encode the number in Base64before sending it. If we don’t , and send it as is, the request will be rejected.

As you can see, something interesting occurred .We gained access to another order submitted by someone else namedRaymundo Linneywith the email address lavina81@heller.com.

This access was not supposed to be available, illustrating an example of Broken Access Control .

And , we did it ! We uncovered a BAC vulnerability.

Next, let’s explore further. As we’ve already covered the login form and the booking feature, we have two more areas to test: the Our Menu feature and Our Locations page.

Starting with the menu page, it appears to be a standard page with the menu and no clickable elements or parameters to manipulate manually.

So, let’s turn on Burp Proxy and see if we can uncover any hidden aspects.

After examining the initial requests, which included only CSS files, Google Fonts API, and other normal files, we found something interesting in the last request. This HTTP request is asking for the resource located at /reviews.php via the loader.php script on the server, with a parameter named f specifying the file name.

Let’s send this request to Repeater and experiment with it to see what we uncover.

So, after rendering the request and seeing its content, it contains some client reviews.

This led me to test for a Path Traversal Vulnerability or LFI (Local File Inclusion) to see if it exists. Unfortunately, my intuition was wrong this time, and I didn’t find anything. The parameter is not vulnerable.

Let’s restart our thinking and approach this from a different angle. It’s time to think more outside the box.

What can we extract from this directory? I remember something we didn’t give importance to earlier: the /admin directory that redirects us to the home page. Let’s try to access it from here and see if it loads.

Interestingly, admin.php didn't give us anything, but admin did.

As you can see, we received a valid response that we didn’t get earlier. It displays a message telling us that we are not allowed to view this page. However, I believe we can find a way to bypass this restriction.

Wait a minute 🤨 how does this page know that we are not allowed to see its content?🤔 Have you asked yourself this question before ?

Something must be telling the web app that we are strangers and not authorized to access it.

Let’s copy this URL to the browser outside of Burp , intercept the request, and examine it. By exploring the requests behind the scenes, we might find something interesting.

Here is a GET request targeting admin.php in the /fastfoodhackings/api/ directory. It includes an adToken parameter, which is empty, possibly suggesting an attempt to bypass authentication.

It seems there might be a token required to gain access to the admin area. If we can obtain this token value, we might be able to log in as an admin.

First, we should check for this token in the JavaScript files or within the elements loaded on the website. If we don’t find anything, we’ll explore other options to uncover the token or access method.

Note: The Target feature we’ll use is available only in Burp Suite Pro. It helps by mapping the entire website, displaying every link you’ve clicked and every request you’ve sent. It analyzes all proxied requests and responses, making it extremely useful for thorough analysis.

Our Target functionality will help us by indexing all the files and filtering the relevant ones using the Filter option.

We’ll click on Filter and search for the word “adToken” to find any references to it.

The final result from our filter shows only the relevant entries.

Fortunately, through our investigation, we found the adToken variable within the script.min.js file, which contains a string that might be the token we’re looking for.

We’ve made a great discovery !

Let’s copy this token, paste it into the adToken parameter in the request, and check if it grants us access.

And Perfect! We’re seeing a message saying, “There used to be a flag here,” which indicates that we’ve gained access to admin resources .

So, we did it! We found another Broken Access Control vulnerability that let us access the admin page, which we weren’t supposed to see.