«

»

Jan 05

Print this Post

Cross Site Scripting

Recently a few of my friends had become white hat hackers. This is an interesting predicament for a person like me. I am both a systems designer and developer. My very good friends had more or less become a friendly version of the enemy. Over a couple of beers they recounted tails of how insecure the world is, and how easy it is to prevent. Well I started to think… I develop different websites, and… I am developing the highly anticipated Query Glass. I need to make sure everything is secure if I want for people to continue to trust me, and anything I create.

I set off to learn some hacking to be able to better protect against it. I will readily admit I am not a top hacker by any means, but if I can hack something then it will be easy for any hacker to get in. The first step to learning to hack is to understand the attack, and know how to exploit it yourself. Lately, cross site scripting has been all the rave, so I decided to tackle this exploit first.

The Hack

Cross site scripting (XSS) is surprisingly simple to do. It is scary easy. The idea is to fool the server into executing JavaScript code for you. To do this the hacker will go onto a website, and type something like the below into a typical text field.

” <script> alert(‘Hacked’); </script> ”

It should look something like the below. This hack should work in any unsecured textbox.

Cross Site 1

When the hacker presses enter the browser will send this into the server. Now let us assume that you type this into a search box. In just about any site the search string that you pass is normally written onto the site as a way of allowing the user to see what his last search was. This sounds quite reasonable if you ask me. The secret are the quotes. As anyone that has done HTML development they know that misplaced quotes can cause havoc on the way code is rendered in a browser. Basically, the extra quotes break out the interior and make the code in between be printed onto the final HTML document as regular code. Since it is not encapsulated it will execute on load. Now, the code above is quite benign. The only thing that will happen is a alert box will open that says, “Hacked”. Making an alert box appear means you can execute arbitrary code which is very bad. If you replace “Hacked” with “document.cookie” the alert box will contain all the cookie data. This can include all kinds of personnel user information.

Another devious use of this exploit is to put a header() call between the script tags and redirect the user to another site. Imagine a hacker sends an email out to customers of a certain bank with a link to:

“www.theirbank.com/search?q=header(%27http%2F%2Ftherbank%27)”

They make up a story about a security breach and mandatory resetting of passwords is taking place. They provide the above link as a quick and easy way to reach the site to reset the password. Now your slightly more aware than the typical consumer will mouse over the link to ensure that it is going to where it says its going. The domain looks legitimate. It is certainly the banks domain (theirbanks.com), and there is gibberish at the end of most internet URLs. They will go ahead and click on it.

The user will in fact go to the banks website, but because of the header call hidden in the url which will be written onto the site. The website will execute the hidden code and redirect the user to therbank.com. An email fishing site meant to look exactly like the banks website. The user innocently resets their password, but in reality handed the password over to the crooks. Ladies and gentleman your poor respect for data validation has left a poor old couple without their retirement funds…

Cross Site 2

Preventing the Attack

Now that we know how to conduct the attack, we must now stop it in its tracks. There are a few ways of accomplishing this. You can either filter each URL that goes through the web server and black lists text that looks like cross site scripting attacks. This method of prevention is highly dependent on your web server. I recommend you refer to your web server’s documentation to figure out how to do this method. My preferred method is basic data validation. I normally don’t let my users use any special characters. That simple. I only allow letters, numbers, and whitespace.

Those characters are quite important in the coding world, so by restricting them they cause tons or problems for hackers. To filter out the bad characters I run every input field through the below function.

function valString($str) {
if (!preg_match(“/^[a-zA-Z0-9 ]*$/”,$str)) {
return false;
}
else {
return true;
}

If it is clean I allow the page to load. If it find any issues, I return the user back to the page he put his input into and wag my finger at him, or whatever I want to do to the user. One thing is for sure. I don’t allow the page to be loaded with the code.

So that is it. Keep coding and keep it secure.

 

Leave a Reply

%d bloggers like this: