Articles

What is XSS (Cross Site Scripting)?

So what is XSS, well firstly that acronym is a little confusing, as it stands for Cross Site Scripting, so should be CSS surely. But if you’ve been reading these more techy updates I’ve been doing, then you’ll know that CSS stands for Cascading Style Sheets (read more about those by clicking here).

XSS is another way of hacking a site, but not this time anything to do with breaking into it and taking control. It’s actually a way of hacking that is more true to the original use of the term, it’s a way of making a site do something it’s not really supposed to do. And yes, that can be used to cause problems for users.

Cross Site Scripting (XSS) is putting code into a website somewhere where it will be displayed and run on the site. So for example, when you make an account on social media say Facebook, it’ll ask you your name, which will then be displayed on the page when someone visits your profile. Now imagine you could put absolutely anything in there, and it was just displayed without any filtering. So if you put in <b>My Name</b> (if you read the What is HTML article you’ll know all about that) your name would be displayed in bold. Which would be a cool little hack so that your account looked different than everyone elses, and you look a bit like a l33t hax0r. So that might be something that the designer of the social media site might want to leave in, a little bonus for people who know how.

Now, what if you could put in code that will run in the Browser, like some Javascript (again, if you’ve read the What is Javascript article, you’ll have some idea about what I’m writing about). So if you put in something like the below┬áinto the name box?

<script>
 alert("Hello, my name is Bob!");
</script>

Well, if it was totally unfiltered, then an alert box would pop up saying “Hello, my name is Bob!”, every time a page which was supposed to show the users name was loaded.

Which again, might be something kewl that a designer might want to leave in. But how do you know that the code being run is totally innocent, how do you know it’s not doing other things, like clicking buttons on the page (something Javascript can do), or taking you to another site, or even downloading code onto the visitors computer?

Well, simply put, you don’t. So by default all Javascript, and probably all HTML should be cleansed from all inputs. Why HTML as well? Because HTML allows such things as

<iframe src="http://www.scruffydug.com"></iframe>

An iframe allows the inline loading of a separate web page, or indeed entire site within another, so quite simply, even if Javascript was blocked from the input field, someone could open up another webpage, which contains the malignant code.

So even though it sounds a little dirty, every web developer should make sure he cleanses his inputs to avoid XSS. Quite simply, never trust anything from the user side of the website, whether it’s input boxes, cookies, uploads or anything else. Don’t let it be displayed on your site without being filtered, don’t let it near your database without being filtered, and certainly don’t allow the file to be accessed on your server without being checked and filtered (imagine if you allowed a user to upload their picture, but didn’t check the file at all, the user could upload a script instead which would allow them to seize control of the server if they so desired and then just run the script (which would be trusted by the server as it was uploaded seemingly legitimately) by coping the image url into the address bar of their browser).

So how do you filter out unwanted inputs? Well, simply put, you’re probably best to find a library which does this for you, someone elses code which takes angle brackets and converts them to character codes, which filters out and removes Javascript, and provides a level of security for your site. Why trust someone else? Simply put, because this is a massive job, you need to be aware of all the tricks to get around this security people will use, using break characters to avoid filters, using nested instructions to avoid detection, writing obfuscated code such as

var _0xc5b2=["\x6F\x6E\x6C\x6F\x61\x64",
        "\x48\x65\x6C\x6C\x6F\x20"];window[_0xc5b2[0]]=
    function (){alert(_0xc5b2[1]+username);} ;

or even

eval(unescape("var%20_0xc5b2%3D%5B%22onload%22%2C%22Hello%20%22%5D%3Bwindow"+
  "%5B_0xc5b2%5B0%5D%5D%3Dfunction%20%28%29%7Balert%28_0xc5b2%5B1%5D+username"+
  "%29%3B%7D%20%3B"));

Both of which decode to

window.onload = function() { alert("Hello " + username) };

Working out ways to avoid that is someone’s full time job, and unless you’re truly brilliant, and truly committed, you’re going to miss something, somewhere, and there’s going to be something which slips through.

XSS

 

Leave a Reply

Your email address will not be published. Required fields are marked *