Cross-site scripting (XSS) attacks are an old favorite of cybercriminals, whereby they take advantage of code vulnerabilities in websites and applications that enable users to add their own content.
Although these attacks have been on the radar of cyber professionals since Microsoft security engineers started using the term “cross-site scripting” back in 2000, they remain a significant problem, and have been an ever-present in the OWASP Top Ten Web Application Security Risks for several years.
The best way to protect a website against XSS vulnerabilities, which are also known as “injection attacks,” is to implement a rigid content security policy to prevent malicious code from causing mischief. Let’s take a closer look at what XSS vulnerabilities are about and how a content security policy (CSP) helps to prevent malicious injections.
What Is An XSS Attack?
With this malicious code, clever cybercriminals can access and steal various bits of data, such as a user’s personal information on an ecommerce site, and also more technical elements such as the browser cookies, which can include login information.
There are two common kinds of XSS injection attacks. Firstly, with persistent XSS vulnerabilities, hackers can use flaws in the website’s code to embed a malicious script on a specific web page. Once that nasty piece of code is added, anyone who visits that website will automatically run the malicious script on their own device. These are the most dangerous XSS flaws, as they can affect everyone who visits that site.
There are also reflected XSS vulnerabilities that only affect a single user when they click on a specially constructed link. Clicking on that link will have the same implications as someone who visits a website with a persistent XSS vulnerability, but such attacks are considered less dangerous, since they require interaction on the user’s part to execute.
What Are The Risks?
In the past, XSS attacks generally targeted the obvious places, such as forms where users are asked to enter information like usernames, passwords, email addresses, credit card details and so on. Over time, most developers have come up with ways to defend these input mechanisms from XSS attacks, but that doesn’t mean their defenses are watertight. Far from it, in fact, for there are many more subtle user input mechanisms that developers may not consider.
For instance, someone who uploads an image to a website could add malicious code via the image file’s metadata. For the web page, that metadata is just another input mechanism that’s waiting to be exploited, but among developers, it is often overlooked.
Malicious code inserted into a website via an XSS flaw can do all kinds of nasty things, but the most common action is to steal the user’s cookies.
By stealing a user’s cookies, the attackers can impersonate that individual whenever they access the website. Cookies are stolen by inserting the malicious code into a form. Once that code is running, anyone who visits that page – or clicks on a link, depending on the type of attack – will download and execute that code within their own browser.
XSS malware generally works by extracting the cookies from the user’s session, then sends it directly to the attacker. The hacker is then free to impersonate that user and from there, it may be possible to steal their login data, billing information or other sensitive information.
Blocking XSS Attacks With A Content Security Policy
CSPs allow developers to restrict which resources can be loaded on a web page, and prevent the execution of any code that isn’t necessary for the page or app to display and function correctly.
To get a little more technical, developers start by defining the CSP directive to control various elements as they require. They must then decide whether or not to allow inline scripts and eval functions. By default, CSP headers will block both as being potentially malicious, but developers can choose to allow some. The CSP also allows developers to determine if they’ll permit HTML style attributes or not. Finally, the CSP adds the ability to report policy violations to the main server hosting the website or app, meaning any attempted injection attacks can be tracked.
Most CSPs will be implemented on the actual host server of the website, but if the hosting provider doesn’t allow for server configuration, it can also be enabled in the header using meta tags.
Advantages Of A Content Security Policy
In general, there’s no excuse for any website or app not to use a CSP these days, as XSS attacks have become ubiquitous across the web, and many are even automated. Hackers even use special software to scour the web for potentially vulnerable websites they can attack, meaning every site is at risk. What’s more, XSS attacks are generally successful once the malicious code has been injected into the target site, as most browsers are unable to distinguish between it and the legitimate code.
Even the most secure and well designed websites can have vulnerabilities that the developers have overlooked. Bear in mind that hackers are extremely determined and spend much of their time and energy looking for flaws in code bases in order to inject their malware.
In addition, CSPs can help to enforce best practices for cybersecurity. They help to lock down many potentially malicious actions, significantly reducing the avenues for attack. They work well in concert with other security techniques, such as vulnerability scanning, template systems and manual code reviews.
Developers Have A Responsibility
These days, much of the talk in the cybersecurity space is focused on ransomware and phishing scams, and that means old-school techniques such as XSS attacks are sometimes overlooked. Although these exploits are a couple of decades old, they remain a very big and dangerous threat, and complacency on the part of developers means such attacks still regularly hit the headlines.
Implementing a CSP is a relatively simple task that will protect against one of the most common and dangerous kinds of cyberattacks. As such, doing so should be one of the top priorities for any website developer.