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

bugbountytraining.com/FastFoodHackings

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

(Part I)

Last time , we found an HTML Injection Vulnerability . Let’s keep going and try to escalate it into XSS .

So, basically, we’ll replace the h1tag with a <script> tag and change the script content to alert(something) to see if we get an alert pop-up when it's executed successfully.

Here's the trick: we'll remove the last >, because the web app automatically appends the closing tag, as we saw in previous examples .

So, we got our alert reflected here, but it doesn’t do anything because the web app uses some kind of filtering to prevent injecting JavaScript into the HTML .

However, we’ll try other methods and payloads to bypass this filter. One of my favorite XSS payload repositories is the XSS.js.org website, which contains a large number of great payloads.

Let’s try some of them manually. If that doesn’t work, we’ll use Burp Suite Intruder.

After four failed attempts, the fifth one finally gave us the desired result: XSS found!

And here is the used payload

Or we can simply

Also , remember to omit the closing tag > from the payload as we did earlier .

And we did it , we achieved the desired XSS !

Now, let’s return to the home page and explore further. We’ll start by examining the booking form to see if it has any vulnerabilities.

First, we’ll perform some manual testing. If we don’t find anything, we can use automated tools to dig deeper.

So, as a normal user, we’ll fill out the form inputs and observe how the web app behaves.

After filling out the form, the web app displays: “This order is pending confirmation.” I also noticed that it redirects from book.php to confirmed.php , huum interesting .

After some manual attempts and testing, we didn’t find anything interesting. Let’s intercept the request through Burp Suite to see if we can find something .

Here’s the request :

We didn’t find anything unusual except the data sent from the form.

After some investigation, I noticed something interesting, whenever we write into the form, the data gets Reflected in the source code within the value attribute. Here is an example:

From this discovery, I think we can achieve a Reflected XSS.

Let’s intercept the request again and try injecting some XSS payloads from our repo XSS.js.org , we hope we can successfully exploit it.

So, as always, after many failed attempts trying to find the winning payload, we finally found it.

Out of curiosity, I wanted to determine which input field is vulnerable.

After retesting, I discovered that the Dateinput is the vulnerable field in this form.

And I got the same result as above .

Here is the source code. As you can see, the script tag in the Full Nameand Email Addressfields is being placed within the input box, which means these inputs are not vulnerable.

However, in the Date field, we don’t see anything initially. When we inspect the code, we notice the selected Datefollowed by the closing tag ”> we inserted, causing our script to be treated as part of the page’s code.

Good achievement for now, but there’s still a long way to go. Let’s continue our journey in the next part and see what other vulnerabilities we can uncover.