FirstBlood-#607 — DOM-based XSS on /login.php via the goto parameter
This issue was discovered on FirstBlood v2
On 2021-10-26, 0xblackbird reported:
Hello! The DOM XSS that I reported a while ago is still unpatched. This issue can still be exploited by crafting a payload and appending it to the url. This can lead to account takeover of course.
Proof of concept:
Steps to reproduce:
/drpanel/drapi/editpassword.php. More info in my previous report).
Visit the proof of concept URL and use the following test credentials:
test. Click on "SECURE LOGIN".
- And normally the confirm box should pop-up:
- The issue here (viewable from the blank page after redirection):
Of course a bad actor would not just go for a confirm box and stop. That's why I decided to prove the impact of this bug. In the following proof of concept, I'm going to demonstrate that it's easy for an attacker to send his/her victim a special crafted link and after that the victim has logged in, send the cookies to the attacker's end. There are a few possible ways to do so, one way is to just redirect the victim to your server with the session cookie(s) appended as the value of a GET parameter for example.
- First of all, visit the other proof of concept URL (to proof the account takeover, make sure you adjust the URL in the PoC). And repeat the previous steps (entering the test credentials).
- Next, click on "SECURE LOGIN". I used webhook.site to view the parameters (since I don't have a server available for the moment), you can of course also setup a local server just for demo purposes. And after logging in, you should see the cookies in your URL bar as well as a the request coming in on your side with the cookies.
Thanks! Have a nice day!
FirstBlood ID: 39
Vulnerability Type: Reflective XSS
Our mistake: The parameter "goto" on login.php should of been "fixed" when redirecting to prevent XSS but due to an oversight from Sean and Karl, the new code did not make it into production. This has since updated since the event ended and you're recommended to re-try. It's related to bug
ID 26 because the idea was developers fixed *this* one (when redirecting) but forgot the other reflection.