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

bugbountytraining.com/FastFoodHackings

This website was created by a skilled bug hunter named Sean (zseano). Its purpose is to assist people in learning bug hunting. Therefore, all the bugs featured on this website are inspired by real vulnerabilities discovered by Sean and other esteemed bug hunters in the field. Every aspect you encounter here, including the technologies employed, mirrors those used in real-world websites. The bugs we uncover are genuine issues that have been observed in practical scenarios.

First, let’s explore the entire application, we’ll scroll through the pages to see what’s going on and learn about the technologies used in the backend, this will help us understand the application better .

During our information-gathering process, we find out that the web pages are created using PHP. This could be useful later.

Our first step is to check the robots.txt file. This file can reveal important information. In this case, it shows us two directories: admin and go , let's explore these directories to see what we find.

After exploring the admin and go directories, we get a 404 Not Founderror. This means these directories don’t exist or aren’t accessible.

Since we know that all pages are created using PHP, let’s try adding .php to the end of the directory names , first, we’ll try admin.php. This works, but it redirects us to the main page.

Next, let’s try accessing go.php to see what we find.

After some investigation and attempts, we discovered an Open Redirect Vulnerability. We can exploit this vulnerability using the following payload:

When users click on this link, they will be redirected to the malicious site , in this case “Google.com” , we successfully exploited the vulnerability and confirmed our first bug .

After finding our first bug, an Open Redirect Vulnerability, our payload successfully redirected us to Google.com, however, i noticed something interesting in the URL: /#type=0. Curious about this, i decided to investigate further. A quick search revealed that the website's JavaScript might read this fragment to dynamically change the page content without reloading it. For instance, #type=0 could be used to load specific content or trigger a function , So ,i intercepted the request and experimented by changing the 0 to other numbers, hoping to uncover something interesting. Fortunately, my approach was correct, and Burp Suite revealed some fascinating results.

So, i changed the request to:

This modification led to an interesting discovery. Now, the response contains some JavaScript. Changing the value of the typeparameter resulted in this change in the response.

I guess now we can execute some JavaScript code and maybe achieve an XSS vulnerability. I tried injecting the following payload, as mentioned in the article under the section titled Exploiting an Open Redirection Vulnerability to Execute Code :

At first, nothing happened. After some investigation, I discovered that I should remove the &type=1 because it might break my payload since it's not JavaScript code. To fix this, I added ; to finish the JavaScript statement and // to comment out the rest. This way, anything that follows my exploit will be treated as a comment and ignored .

Perfect! As you can see, our alert message executed on the target, indicating that we have discovered a Reflected XSS Vulnerability.

Now, we’ve identified two bugs: an open redirection and an XSS . Let’s return to the home page and search for something interesting to test. My intuition suggests we should examine the login form. We might discover another XSS vulnerability , SQLI or something else. Let’s test its behavior and see what we can find.

Let’s go ahead and try logging in with some casual credentials to see how it behaves. but, intuitively, we might encounter an error.

However, something in the URL caught my attention: the act=login parameter. Let's test it to see how it behaves and what we can do with it. It might be vulnerable.

Let’s changelogin to something else, like aaa, and see if the value is reflected anywhere on the page. Initially, the page loads normally without any visible issues, but it might be injected somewhere that's not immediately visible. To check, we should examine the source code.

We found it commented in the first line above the HTML tag: <!-- invalid action: aaa -->.

We want to break out of this constraint, which is the fact that any word we type is placed inside this comment.

To bypass this, we need to make our text part of the page. We can do this by closing the comment tag before our input is read. Let’s copy the close comment tag (-->) and place it before aaa to close the comment.

We successfully did this, and it works perfectly, making our text part of the page .

Good achievement for now, but there’s still a long way to go.

I initially thought of XSS and tried some basic payloads, but nothing happened. Then I considered HTML injection.

Luckily, this worked, and I discovered another bug: HTML injection .