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

bugbountytraining.com/FastFoodHackings

Welcome to the fourth 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 , second or third parts, be sure to check them out. Let’s continue our journey into uncovering bugs !

(Part I) (Part II) (Part III)

By examining this request further and checking for additional parameters to test, we might discover something interesting, just like we did in the previous part when we found the token that allowed us to log in as an admin, regardless of our existing authority.

So, we’ll continue using Burp Suite to search through the code and files for the parameter f=, hoping to find something useful.

Wow! This is the greatest discovery so far , we’ve finally found the credentials! I’m pretty sure these are the admin credentials.

The credentials are as follows

And here you can see our admin panel. It might seem empty, but we’ve done a great job by examining this parameter and gaining access to the panel.

It seems there’s nothing to do here , no clickable elements or inputs. But, just like we’ve done every time we’ve faced this issue, we’ll turn to our trusty friend, Burp Suite, to discover any hidden elements.

After reviewing the request, we only found some CSS and API font files as always . However, the last request includes an id= parameter that could be worth testing. Let's investigate it to see if it reveals any path traversal vulnerability .

After testing various path traversal payloads, I didn’t find anything. However, I accidentally changed the id to 0, 1, and other small integers.

While 0 yielded no results, both 1 and 2 produced interesting findings.

By assigning 1 to the id= parameter, it displays 'Test account for zseano' .

And , by assigning 2 , it displays 'Bio for account two. not much interesting here sorry’ .

And now we’ve confirmed our findings , we’re able to load data belonging to other users by accessing their accounts.

We’ve discovered an IDOR (Insecure Direct Object Reference) vulnerability.

So far, we’ve tested almost everything on the website, from the login form to the menu page, and we’ve clicked on nearly every visible button. As a result, we’ve discovered several bugs, including Open Redirects, XSS vulnerabilities, and Broken Access Control.

Whether you’ve noticed or not, Our findings have come from hidden Endpoints and parameters. So, let’s continue with this methodology and approach, hoping to uncover more bugs just like before.

We’ll be using an Advanced Technique called Regular Expressions, or in short Regex, to search for specific patterns in text. This powerful tool will help us identify hidden parameters, endpoints, or anomalies in the code that might otherwise go unnoticed. Our goal is to conduct an in-depth investigation within all the files we’ve intercepted through Burp , uncovering hidden information .

We want Burp Suite to search for any sequence of characters that matches this pattern: starting with a question mark ?, followed by some text, and then followed by an equal sign =. The pattern would look like this: ?.*=

In Regex, the . represents any character, and the * means any number of characters. However, there are some tricks we need to include.

First, we'll add a backslash \ before the ? to tell Burp that the ? is part of the pattern, not a special character. Additionally, we'll add a ? before the equal sign = to instruct Burp to stop matching once this pattern is satisfied, rather than continuing to the end of the line.

So, the final pattern will look like this:

A bit of investigation through the files revealed several pieces of code matching this pattern.

While most were uninteresting, except the?promoCode=UKONLY in the book.php file.

After visiting book.php with the promoCode=UKONLY parameter and testing it, nothing happened, and we were simply redirected back to book.php.

But, there’s something to note: we found the promoCode parameter on book.php, but we were actually investigating menu.php. Let’s take another look at the menu.php page and inspect the source code.

We noticed that the promoCode value is stored in a variable on this page. This could be interesting enough to investigate further.

If we manage to discover an XSS vulnerability, it could lead to stored XSS, which would execute for anyone who loads menu.php.

This is already placed between <script> tags, unlike our previous attempts. However, we’re facing some challenges this time.

Since the value is assigned to a variable and enclosed in single quotes ‘_’, anything we type will be treated as normal text and not part of the code. We’ll need to play with these quotes to break out of the text context and execute our payload .

After numerous failed attempts and trying to figure out how to manipulate the input to achieve our goal, we finally succeeded in finding the right format.

We were able to bypass all filters and achieve our desired objective .

We’ve discovered a Stored Cross Site Scripting vulnerability .

To inject our code, we need to break out of the existing string. We do this by adding another quotation mark (') and a semicolon (;) to end the current statement. The initial injection looks like this:
var promoCode = 'UKONLY';';

Next, we try to inject a simple alert to test if our code executes. We add alert("XSS") after the statement, and to prevent syntax errors, we comment out the remaining characters with //. The payload now looks like this:
var promoCode = 'UKONLY'; alert('XSS'); // ';

This should give us two valid JavaScript statements, which should execute properly. Unfortunately, a filter modifies our payload, resulting in:
var promoCode = 'UKONLY'; ('XSS'); \\ .The alert function is removed, and the forward slashes (//) are replaced with backslashes (\\), causing our payload to fail.

Since the alert function is filtered out, we try doubling it up like aalertlert. Instead of commenting out the rest of the code, we complete the statement with a valid piece of code to avoid errors.

The final working payload looks like this:

This bypasses the filter by using an unconventional method and completes the script with a simple, valid statement.

As we know, its automatically adds the double quotes (' ') and the semicolon (;). So, when crafting our payload, we only need to copy the code inside, without the first and last single quotes and the semicolon.

So we did a great job by discovering an IDOR vulnerability that allowed us to log in to the admin panel, as well as uncovering a slightly complex stored XSS.