Cross-site scripting, otherwise commonly known as XSS, is a popular attack vector and gets its fair share of the limelight in the press, but why is it such a problem and how is it caused?
Essentially, XSS is a code vulnerability in a website that allows an attacker to inject malicious client-side scripts into a web page viewed by a visitor. When you visit a site that has been compromised by a XSS attack, you will be inadvertently executing the attacker’s program in addition to viewing the website.
This code could be downloading malware, copying your personal information, or using your computer to perpetuate further attacks.
Of course, most people don’t look at the scripting details on the website, but with popular wikis and web 2.0 content that is constantly updated and changed, it’s important to understand the ramifications from a security stand point.
In order for modern websites to be interactive, they require a high degree of input from the user, this can be a place for attackers to inject content that will download malware to a visitor or enslave their computer, and therefore it is hard to monitor an ‘open’ area of the website and continually update and review their websites.
> See also: Cyber security: do you know where you stand?
XSS code can appear on the web page, in banner ads, even as part of the URL; and if it’s a site that is visited regularly, users will as good as submit themselves to the attacker. In addition, as XSS is code that runs on the client side, it has access to anything that the JavaScript has access to on the browser, such as cookies that store information about browsing history.
One of the real concerns about XSS is that by downloading script on a client-side computer, that endpoint can become enslaved into a botnet, or group of computers that have been infected with malware in order to allow a third party to control them, and used to participate in denial of service attacks. Users might not even be aware that they are part of an attack.
In a recent case, we identified how a popular denial of service engine called ‘JSLOIC‘ was used as script in a popular website, making any visitor an unwitting participant in a denial of service attack against a third party for as long as that browser window remained open.
The range of what can be accomplished is huge- malware can be inserted into a legitimate website, turning it into a watering hole that can infect a visitor’s computer; and this can impact anyone. Once the XSS is put into a website, then the user becomes a victim and the attacker has is all of information that the browser has.
In terms of preventing it; firstly, the hole in the website that has been exploited has to be closed. The main tactic to prevent XSS code running on your website is to make sure you are ‘locking all the doors’ and reviewing your website code regularly to remove bugs and any vulnerabilities.
> See also: Businesses underestimating the threat of DDoS attacks
If you are doing it properly, it should be a continual process. If a website has malware on it due to the owner not reviewing it regularly, then attackers will be able alter the malicious code to dominate the page and infect more visitors.
You can limit the chances of getting malicious code on your website by routinely auditing the website for unintended JavaScript inclusions.
But with XSS, especially non-persistent XSS, the best thing is to validate all data coming in, don’t include any supporting language and make sure what is coming in is sanitised, or checked for malicious code. This is especially true for parts of your website that get regular updates, like comment sections. It is not enough to just assume that because it clean before, new updates will also be also be clear.
Even if you are following proper security coding and go through code reviews, websites are sometimes up for six months with no changes made, that is why vulnerability testing is important as new bugs come up. Remember, HTTP and HTML are full of potential vulnerabilities as the HTML protocol was written in the 1960s; it was never imagined it to be what it has become. So when writing website code, if you do not consider SQL Injection or XSS, then you will write a website full of holes.
Top three tips:
– Review your website and sanitise your code regularly to ensure there is no malicious code or holes where code can be inserted.
– Consider not allowing comments to host external links, or even approve those links before they are published to prevent code from being inserted easily.
– View your web traffic in and out of your website for signs of unusual behaviour.
