So far in this series we have seen various techniques to prevent both HTML and SQL Injection attacks. This is the third article in the series to show you some of the techniques about how Cross-Site Scripting (XSS) come about and how you can prevent them.
So, what exactly is cross-site scripting? Well, as the name suggests, these are attacks which force your site to redirect or make use of resources from another site. As an example let's take the comment form at the bottom of this page, if I was to allow the use of BBCode then the following scenario is entirely plausible.
The point of BBCode is to allow the easy formatting of posts messages by using a series of markup tags such as [URL][/URL] or [IMG][/IMG]. Typically the content found within the tags is substituted as the src or href attributes of their respective tags, i.e.
would translate to
Seems easy enough to handle then, but what would happen if someone put the following:
[URL]http://matthewkellett" onmouseover="window.location.href = this.href;[/URL]
If the code within the tags was simply substituted into the href attribute of a standard URL then you would end up with the following:
<a href="http://matthewkellett.co.uk" onmouseover="window.location.href = this.href;">http://matthewkellett.co.uk</a>
Given that the majority of people tend to read with their mouse then as soon as they got to this section of the page they would be redirected to a completly different page. Whilst this is a basic simple example, with a bit of imagination you could potentially redirect a user as soon as the page has finished loading by putting the correct code inside the [URL] section of a comment.
Imagine you run a site that has 10,000 users who all frequently log in to your site, now imagine your site has been susceptible to this type of attack and ask yourself how detrimental the following sceanrio would be for your site and business?
Someone has managed to replicate your log in page and inject a URL into one of your comment boxes in a similar way to the above. How many of your users would instinctively enter their log in details into the form being displayed to them?
Now I'm not going to demonstrate this here as it would mnean nobody would be able to read the article, but I hope this shows how a very simple comments box can prove to be dangerous.
Hopefully you can see how detrimental this type of attack could be to both your site and you business but there are plenty of preventative measures you can put into place to stop this type of attack from occuring. Again it comes back to cleansing all user input regardless of how trusted you believe the source to be.
In conclusion, it should be simple to see that if you capture any form of input from a user that it should be cleansed before using it in anyway shape or form.
If you have the read the previous two articles on HTML Injection and SQL injection then you should see a pattern emerging, all three of these attacks make use of user input either from a form or the URL and should be cleansed prior to be used.
Thank you for taking the time to read this article and I hope it has been of some use to you, the next article in the series will cover off some of the techniques and processes that can be used to help both identify and elimiate the risks around running a website.
There are no comments for this article