0

Protecting your applications against XSS attacks

Nowadays hacking has become so easy that even children can do it and one of the most prevalent forms of attack is Cross Site Scripting (XSS). I will briefly explain what this form of hacking is and hopefully by the end of this post you should be able protect your applications from such attacks.

Websites are using more and more user generated content now and it is this exposure to dynamic content that allows hackers to plant mischievous code. The reason this works is down to the way your browser interprets the HTML of a site. As soon as it comes across a <SCRIPT> tag it will attempt to execute whatever JavaScript is located within it. If a third party is able to run JavaScript without you knowing, then they can potentially access any information the browser holds such as cookies, sessions or even redirect you to other sites.

Persistent Vs. Non-Persistent XSS

XSS boils down to two main types: persistent and non-persistent. Persistent XSS can potentially be more damaging as it involves a server storing content submitted by a user. For example if you register for a website and set the username to “<SCRIPT>alert(“hello there”)</SCRIPT>” then each time you load a page where the username is displayed you will receive a JavaScript alert box welcoming you. Now replace that harmless script with malicious code and anyone who views the value for your username will potentially be at risk. What is even more worrying though is that if this username value is used in an SQL query then your application could be tricked into exposing sensitive data by modifying the query or even deleting data, this is also known as a form of SQL injection. However persistent XSS attacks like this can be caught by “cleansing” your inputs. Each time user content is submitted just make sure that it only contains alphanumeric characters.

Non persistent XSS is a different kettle of fish as it involves modifying the URL to embed scripts directly into the HTML. Say for instance the URL parameter “&name=” is used in your application to simply print out the value without any processing. Then a malicious user could modify the value of this parameter to include some devious scripting e.g. “&name=<SCRIPT>….</SCRIPT>”. Once again this can be prevented by cleansing any URL parameters that are used for creation of HTML.

Cross Site Request Forgery (XSRF)

XSRF is a more serious exploitation of cross site hacking technique. For example if you are using an online bank to transfer money and then leave the site without logging out your session will still be active. If you subsequently view a mischievous website that has an html element which knows your session is still available then it can be used to perform an action on the banks website without you even knowing. The html element might look like this: <img src="http://www.mybank.com/withdraw?account=current&amount=1000000&to=Fred&accnum=12345678">. Banks are now starting to be more aware of cross site requests and most are now requiring the use of a card reader to make withdrawals. But another simple way to stop this from happening is to log out of your bank account when you are finished!

What can I do?

So hopefully, when developing applications, you will now be aware of the threat that XSS poses, but the trick is to be clean! However you must also be aware that it is out there and when browsing the web be vigilant at all times.

About Paul Thomas

Paul is an expert Google Search Consultant and a key member of the Information Governance Business Unit.

Leave a Reply

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

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>