Open Redirect Exploit & Reflected XSS
Reflected Cross Site Scripting
This exploit allows an attacker to send a link from www.minecraftdungeons.net and execute their own javascript code... and since you guys store all sesssion tokens in the document.cookie variable I can send the users login details to my server and therefore hijack accounts of targetted users.
Note: This exploit requires no user interaction if the target is already signed in. But the exploit can still occur after the user is signed in.
Here is a proof of concept of JavaScript execution.
https://www.minecraftdungeons.net/en-us/login/?returnUrl=javascript:alert(document.domain)
Open Redirect
The next exploit I will address is the open redirect. This will allow an attacker to redirect a user to their own malicious website to preform a phishing attack or something of that nature. It works the same as the last exploit but instead of a data / javascript URI it uses a link as so:
https://www.minecraftdungeons.net/en-us/login/?returnUrl=http://google.com
This will redirect you to google from the minecraftdungeons domain, if signed in.
Example of usage
**Alright, time for an example. Lets say im a spooky hacker man trying to hack Pewdiepies minecraft dungeons account... I would have to trick him into clicking my malicious link which looks like this:
https://www.minecraftdungeons.net/en-us/login/?returnUrl=//shorturl.at/mGMZ3
This will direct Pewdiepie to to a URL shortner which is hiding my big javascript payload which is actually sending all his data to my own website.
(The link I sent above will just give you an alert with your cookies and not actually send it to my own server.)
How you could fix this
Make a white list for what URL's the returnURL parameter can redirect to. If that is not possible for your case, I would maybe check if it is redirecting to a website and not a data URI or something of that nature.
And to address the cookies, you might want to store those as HTTP-Only Cookies to prevent account hijacking in future cases.
Donations / Rewards are always accepted ![]()