Self-XSS is a curious case of cross-site scripting: an attacker is able to execute code in the browser, but only he/she can do it. No link to share, no common place to be visited by someone else in case of a stored flaw (like in restricted profiles). It’s confined to the place where it runs, which makes the attacker and victim the very same person.

But even in such an infertile scenario it’s possible to leverage it to a successful attack. Here are the main proceedings to turn an useless reflection into a dangerous one:

POST to GET

It’s just a matter of finding the parameter which is being accepted both via GET and POST methods on server side like the PHP’s $_REQUEST[‘parameter’] global variable, much seen in search fields. JSON calls also might be responsible for retrieving the output, so it’s worth checking the requests made by application for GET parameters used in client side scripts.

Copy & Paste

Users can be tricked into craft the XSS themselves, by copying and pasting a code provided by attacker. Although far from being the best option, it’s still valid code running in the context of a vulnerable application.

XSS + CSRF

Most websites usually don’t care about CSRF (Cross Site Request Forgery) when it affects the logout feature, so it might be possible to log out the current user from his/her session on the website and login him/her again using an account we create and control in order to trigger the XSS.

A basic scheme follows, with common needed data (to be provided by an attacker) in uppercase:

<iframe src=LOGOUT_URL onload=forms[0].submit()>
</iframe><form method=post action=LOGIN_URL>
<input name=USERNAME_PARAMETER_NAME value=USERNAME>
<input name=PASSWORD_PARAMETER_NAME value=PASSWORD>

This uses a combination of an iframe to perfom the logout and a form to submit the known login credentials. The problem is the victim sees the content of the vulnerable page, which could make him/her spot the attack. But, as soon as the javascript code is executed, lots of things can be made to ensure the victim won’t notice the malicious activity.

In the following video we can see the attack occurring against a locally hosted sample application, by means of an external domain (brutelogic.com.br) to execute the code in admin user’s browser:

Payload used in video:

<iframe src=//localhost/self/logout.php
onload=forms[0].submit()></iframe><form method=POST
action=//localhost/self/login.php?returnURL=changemail.php>
<input name=username value=brute>
<input name=password value=logic>

#hack2learn

P.S.: code for the vulnerable application used in video will be available soon for practicing.