They’ve been on the radar screen of IT security teams for years, but cross-site scripting (XSS) attacks continue to pose a significant risk for organisations of all sizes.
Taking advantage of coding flaws in websites or web applications, they provide cybercriminals with a powerful and flexible way to gain access to infrastructures to steal data or cause disruption.
XSS attacks make use of the way in which many websites and applications dynamically gather and display data from each individual visitor. Popular techniques use features such as comment sections or user-placed reviews to which visitors can add text.
If the developer of the site has failed to include some form of checking of visitor input before it’s displayed, it is possible to add malicious code along with text. Such code can remain invisible to other users yet cause problems until found.
Types of XSS vulnerabilities
There are two key types of XSS vulnerabilities. In the first, dubbed a persistent vulnerability, attackers use flaws to store or add a malicious script to a page of a site or application which remains in place until it is discovered and removed. Anyone visiting such an infected page runs the malicious script.
The second type dubbed reflected XSS, only affect one user at a time and require the user to click a specially crafted link. Malicious scripts for reflected XSS attacks don’t exist in a web application or site forever. Instead, attackers use embedded links with which victims must interact, and then only run in that user’s browser.
In the past, XSS vulnerabilities tended to be found mostly in web application ‘surface’ inputs, such as in the type of form fields where sites may ask visitors to enter their names, email addresses, or credit card details.
These days, now that web developers better understand XSS attacks, they generally do a pretty good job of sanitising such obvious input mechanisms. However, there are many subtle website input mechanisms that developers may not think of as user-controllable. For example, when a user uploads an image, a web application may parse that picture file for its metadata.
That metadata is actually an input mechanism to the web application that developers may not think to sanitise, however, attackers can edit the metadata to include their malicious script. In short, many web applications have become much better at protecting obvious input mechanisms, but many others are easy to overlook.
The COVID-19 element
The widespread shift to at-home working as a result of the COVID-19 pandemic might have brought some significant new security challenges, however, XSS risks haven’t changed dramatically as a result. Though XSS vulnerabilities directly impact the visitor of a web application, they reside in the web application or the website itself.
However, as organisations quickly shifted into remote working mode, many opted to expose previously internal web applications to the internet or sign up for new cloud services. Cybercriminals have noted this increase in attack surface and there has been a steady increase in the number of XSS attacks being mounted. This is a trend that’s likely to continue in the months ahead.
Detection and prevention
When it comes to detecting XSS attacks, the most effective method is by using a web application firewall. These firewalls differ from typical network firewalls, and they can monitor all the specific input parameters of a web application. The firewall learns the types of inputs a web application is supposed to collect, and if they detect any unusual input, they can prevent it or raise a flag.
When it comes to XSS prevention, the best means is to use secure code on websites and in web applications. This is both simple and complex at the same time, but in general, involves two steps.
Firstly, it’s important to ensure that whatever web code frameworks are in use are up to date. Web framework creators do make secure coding mistakes, and their code can introduce XSS flaws. Therefore, code must be regularly checked to resolve potential vulnerabilities.
Secondly, even if existing web frameworks are being used, there is still likely to be significant custom code in place. This means developers need to follow secure web coding practices to ensure this code doesn’t introduce vulnerabilities.
The prevalence of XSS attacks is unlikely to decline any time soon, so it is important to take the steps necessary to make your websites and applications as secure as possible. Following this action now will help to prevent loss and disruption in the future.
