URL Based XSS/XST Attack Methods
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
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:
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.