What is ‘Cross-site Scripting’?

Cross-site Scripting (XSS) attacks are a type of injection attack, whereby malicious scripts are injected into trusted websites. An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser is oblivious as to whether the script should not be trusted, and so will execute the script. Because it appears as though that script is from a trusted source, it can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page. More often than not, flaws that allow these attacks to succeed result from poor quality coding. These flaws can be quite widespread, and occur anywhere a web application uses input from a user within the output it generates, without validating or encoding it.

Types of XSS

There are different types of XSS attacks, commonly referred to as Server Side and Client Side. In Server Side XSS, untrusted user supplied data (usually a malicious script) is stored on the web server or a database through an interaction. An example of this could be an attacker inputting a malicious string into the comments section of a website, which is then processed and stored by the server. This in turn affects everybody who then visits that website, as that script is executed every time that web page or application is loaded by a user. It is an incredibly effective technique for hitting many targets at once.

Client Side XSS happens when a user input is reflected on the page without being stored on a database or server. In this instance, an attacker must send a victim a link which they have to interact with before the payload is inserted. The injected attack only impacts users who open that link or third-party web page. The web application in the victim’s browser then actually executes the malicious script.

Example

In 2005 a virus named Samy-worm gained notoriety as it propagated through close to one million users’ Myspace profile pages in the space of 20 hours. Myspace was very liberal in allowing users to customise pages with snippets of code and Samy-worm harnessed this weakness, actually replicating itself to anyone who merely viewed an infected profile. Although relatively harmless, Samy-worm was notable for its record breaking infection rates, and perfectly demonstrates the dangers of XSS attacks and their potential reach.

Protecting against XSS

Unfortunately, XSS attacks can only truly be combatted by the website developers. Education into security-minded programming cannot be undervalued in this day and age, and simple mistakes in web page design are all it takes to cause the most damaging and widespread attacks. All websites should be subject to the security development lifecycle (SDL), as well as undergo regular penetration testing and source code scans.

Validating User Input

Any data that is not from the host system should be treated as malicious! Therefore by checking and verifying that the content adheres to strict admissibility rules such as refusing bad characters or limiting input length; the threat of injected code can be managed to be within acceptable limits. In practice, this means that at every point where user-supplied data is handled and processed, any input accepted from the client side is checked, filtered and encoded before being passed back to the user.

Escaping

Escaping data means taking the data that a website or application has received, and ensuring it is secure before rendering it back to the user. This is done by ensuring that key characters in the data received by a web page will be prevented from being interpreted in any malicious way.

Further Steps

To ensure that you protect against all vulnerabilities related to XSS, the Open Web Application Security Project (OWASP) is a great resource for technical advice for preventing XSS related vulnerabilities. Their XSS Prevention Cheat Sheet covers a huge number of rules that will prevent the majority of common coding errors. They also reference and update lists of safe Javascript APIs and methods for developers to use in their websites, and cover Content Security Policies (which can help protect against XSS by only allowing certain scripts from certain domains to execute in a user’s browser).

If you are willing to go to extreme lengths to protect yourself or your business, one option is to disable scripts on your workstation browsers. This is a radical approach and will completely stonewall any malicious code, but it comes with a steep learning curve, and a potentially drastic reduction in website usability.

If you are responsible for managing a public sector website, you may also be eligible for the NCSC’s web check service, which will scan your website for common vulnerabilities including how well engineered it is. Find out more by visiting the NCSC web checker page.

The South West Regional Cyber Crime Unit is comprised of dedicated individuals who investigate serious cybercrime, offer advice and guidance to small businesses, and work with a range of partners to prevent people from engaging in cybercrime. For more articles and case studies like this, sign up to our Regional Cyber Briefing/ Cyber Intelligence Report, and follow us on LinkedIn and on Twitter (@swrccu).

We also have a node on the Cyber Security Information Sharing Partnership (CiSP), and we strongly encourage organisations to sign up for real time cyber threat information in a secure, confidential and dynamic environment https://www.ncsc.gov.uk/cisp.