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

bugbountytraining.com/FastFoodHackings

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

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

We did a great job in the previous parts by discovering many bugs and vulnerabilities, such as Broken Access control, Stored & Reflected XSS, Open Redirects .

I believe we’ve thoroughly checked every page, clicked on every clickable button, and tested every functionality. However, as we’ve mentioned before, checking the visible elements doesn’t guarantee we’ve covered everything. There are still hidden aspects waiting to be discovered .

To achieve this, we’re introducing a new tool OR actually its a browser extension that will help us uncover hidden elements on websites. This way, we can discover interesting things more easily, similar to how Burp Suite revealed hidden endpoints for us using Regex. Now, we’ll be able to unveil hidden elements without having to dig through the code line by line.

By installing the LazySec extension , Clicking on “ALL” checkbox and clicking the ‘Show Hidden Elements’ , you’ll be able to reveal all hidden elements in the Web App. This will assist in discovering new Features and Endpoints that might be vulnerable .

We’ve found a hidden link that doesn’t redirect anywhere when clicked, which is curious given its hidden nature. Let’s investigate its source code further to gain a better understanding .

Here, we have a link that appears to be invalid, but it includes an id= with a redirectUrl value. IDs are used in HTML to identify elements and are manipulated by JavaScript.

This could be a good hint to go back and investigate this ID further with Burp Suite .

Let’s use the Filter functionality, as we did earlier, to search through all files and uncover the parameters we need.

We found it! Now, let’s try sending another link as a query in the from parameter to see if we can discover an Open Redirect or something interesting.

We successfully discovered an Open Redirect vulnerability.

This time, it’s straightforward: we’ve observed that whatever we enter in the URL gets injected into the href="". Let’s inject some JavaScript code and see if we can achieve an XSS vulnerability.

We successfully discovered an XSS vulnerability .

We now have two more bugs added to our arsenal .

One last thing to check: below the from parameter, there's another one called type, and they seem identical. Let's examine the code further to understand its functionalities .

Let’s break down the code for a better understanding. We’ll set the from parameter to any value and the type parameter to 1, as mentioned in the code, to redirect us to our desired location. We'll concatenate the two parameters with &, followed by what’s written in the code. Additionally, we'll add a # before redir, because redir isn’t a parameter like from and type.

The getHashValue function is supposed to return a value based on the redir parameter. This function likely extracts a value from the URL’s hash portion (the part after # in a URL).

For example, if the URL is http://OiQ.tn/#redir=someURL, getHashValue("redir"),would extract and return the value someURL.

Intuitively, we’ll test this for Open Redirects, just like we did with the previous parameter. Then, we’ll try to escalate it to an XSS vulnerability, hoping for a successful result .

And we did it , We successfully found another open redirect!

By replacing the Google URL and setting redir to javascript:alert('XSS'), we successfully achieved a new XSS vulnerability, confirming that both parameters are vulnerable .

And we did it again , We successfully found another Reflected XSS Vulnerability !