WordPress and Cross-Site Scripting (XSS)

Cross-site scripting attacks are one of the more common types of website attacks seen across the internet. Understanding what they are and how to protect against them is vital in order to safeguard the security of your website, visitors and business. Read on to find out more!

What Are Cross-Site Scripting Attacks?

A Cross-Site Scripting attack (more commonly referred to as an XSS attack) occurs when a piece of malicious code (normally JavaScript) is injected into a webpage with the intention of harming the end user.

This code is typically inserted at the end of the URI (Uniform Resource Identifier) as a parameter or by using a web application on a webpage, such as a user input form. The malicious code will normally be designed to override access control and manipulate the website’s functionality.

Cross-Site Scripting Vulnerability

As we’ve seen, an XSS attack is a web-based attack that uses malicious code in order to access a vulnerable website and undertake harmful activities. The key word in this sentence is ‘vulnerable’. This (unfortunately!) can mean many, many things. A WordPress website that uses ‘admin’ and ‘123456’ as the username and password is vulnerable, even if all other security precautions have been taken. WordPress websites running out-of-date plugins could be deemed vulnerable. Or even a web application that includes user input within a form and does not validate or encode the submitted values would be considered vulnerable.

Hackers who deploy XSS attacks are constantly on the lookout for vulnerabilities that they can exploit. Ones that are more commonly found and therefore open up more websites to attack are, understandably, favored but hackers will seek out more obscure vulnerabilities in order to attack websites that they consider to be of high value to them as a hacker.

The fact that there are so many potential vulnerabilities and all manner of attack types makes identifying the potential weak spots and mitigating attacks a tricky job.

Target Websites

A web-based email server or client, a CRM / ERP System, a publicly available profile page (such as those that are commonly seen on social media sites and membership groups) are just some types websites and applications that make excellent targets for XSS attacks.

Other sites that are typically vulnerable are ones where users can post HTML formatted text that others can view, such as in forums or comment fields.

Types of Cross-Site Scripting

Attacks known as cross-site scripting (XSS) can be broken down into three primary types according to whether the injected code runs on the server or solely in the browser of the person attempting the attack. These are as follows:

• The Persistent (or stored) XSS, where the attacker-injected code is stored on the server permanently.
• The Non-Persistent (or Reflective) XSS, where the attack is made through a crafted URL that the end-user is trickedinto using.
• The DOM-based XSS (or client-side XSS) which, like all the other types, is also performed inside the visitor’s browser, with the difference that it alters the DOM of the site.

Impact of Cross-Site Scripting XSS

The impact any XSS attack may have will vary according to a range of factors. One of the biggest will be the sensitivity of data that is stored and that is targeted by an attack. Comments on a forum about cooking are clearly less sensitive than secrets being held on a national government website!

Typically, the target of an XSS attack is an individual who uses a website or application. Depending on the type of attack and the script injected, the attacker may steal the victim’s session cookies and personal data such as access credentials. An attack may also attempt to lift sensitive information such as credit card data (assuming this is present).  

What’s particularly horrible about XSS attacks is they are effectively masked… so, the user who is targetted can appear as the individual who might be causing malicious damage when, odds are, they have no idea that anything is amiss.

Clearly, the impact of this can be significant on a business. Any hack that damages a website and potentially reveals sensitive information is bad news. Just how bad will depend on the severity of the attack and the impact on your customers.

Protect Your WordPress Site From XSS Attacks

WordPress websites suffer their fair share of XSS attacks. In part, this is due to the sheer number of sites that are powered by WordPress (currently 43.1% worldwide). It’s also as a result of the many XSS vulnerabilities that many WordPress plugins have. In turn, this means, statistically speaking, that the more plugins used on a WordPress website, the greater the chances are of suffering an XSS attack.

Because of this, generally all that you need in order to reduce your WordPress website’s XSS vulnerability to the minimum is to validate and sanitize any variable that could be included in a URL from the attacker. Here are some generic tips along with some other more specialized solutions you can apply to your site in order to help protect it.

Stay up to date!

It’s super crucial for your website’s security to ensure you keep your core files, plugins and themes updated to their latest version. In doing so, you reduce the risk of all forms of attack on your website, not least XSS attacks.

For more details on general steps you can take to protect your WordPress website, make sure you check out our article, How to Secure your WordPress Website.

Deploy the ‘Prevent XSS Vulnerability’ plugin

Perhaps unsurprisingly (as this is WordPress) a plugin has been developed that can help reduce the risk of XSS attacks. It’s called ‘Prevent XSS Vulnerability‘

Once you install and activate the plugin, go to its settings page, under the “Reflected Cross-site scripting(XSS)” menu item that will appear.

The Prevent XSS plugin by default configures a range of entities that are blocked from the URL. This helps stop attacks in their tracks. In addition to the default settings, you can specify further entities you’d like to be blocked from the URL.

The same goes for the entities the plugin encodes in the URL. You can exclude entities you do not wish to be encoded in the tex tarea provided by separating them with a comma.

It also secures vulnerabilities by escaping the HTML in the $_GET parameter. Therefore, if anyone tries to inject HTML in the URL it will not work.

It is very important when you have installed the plugin and finished adjusting the settings that you at least check a few pages at random to ensure that your website is functioning as it should. This is especially critical if you’re using WooCommerce. In this instance, make sure you go through the entire checkout process (including payment) to ensure this works.

Protecting the Output Data

Except for validating the input when it is received from a visitor, you should also encode all HTTP responses that output the data. Practically, this means that every character should be converted to its HTML entity name.

If you are a WordPress developer, there is a great handbook on escaping output data which is worth a read.

XSS Attack Protection with Pressidium

If you host with Pressidium you’ll automatically be enjoying the protection of our Managed Web Application Firewall Layer that will protect your website in multiple ways, including XSS attacks. This allows you to just focus on your business without worrying about your website. Find out more about features of the Pressidium platform here.