Protect Drupal sites against cross-site scripting vulnerabilities
Dan Frost

In the latest of our posts on cyber security and protecting your Drupal websites, we look at one of the more sophisticated tricks used by attackers - cross-site scripting (XSS).

What is XSS?

XSS is a website vulnerability that allows hackers to trick your browser into loading code that neither belongs to the website you are viewing nor comes from other trusted sources used to provide website functionality. Hackers use XSS to execute this malicious code, typically JavaScript, which can then steal data and perform all sorts of other malicious actions.

Cyber attackers can also choose to use XSS on publicly available pages of a website, by injecting their code to target visitors via their own ads, phishing prompts, or other harmful content.

"Almost 40 percent of all cyber-attacks in 2019 was performed by using cross-site scripting, which is hackers’ favorite attack vector globally." (i)

In early 2019, the popular online video game Fortnite by Epic Games almost became a victim of cross-site scripting attacks that might have led to a data breach. The problem stemmed from an unsecured retired web page, giving attackers unlimited access to 200 million users. The purpose of the attack was to steal the virtual currency of the game and record players’ conversations that could provide critical information for another attack in the future.

This is not the only high-profile XSS attack case – other organisations including British Airways, eBay, Facebook, and the CIA have all been targeted through XSS vulnerabilities on their websites.

It's far from just large organisations that get targeted by XSS attacks though. Most are triggered by automated scripts that scour the internet for websites that they can exploit, and so it could happen to any organisation's website large or small - including yours.

XSS is considered the third most critical security risk to web applications by the Open Web Application Security Project (OWASP).(ii)

Although cross-site scripting is an old hacking technique, XSS vulnerabilities are still one of the most common issues found on websites, with the Open Web Application Security Project (OWASP) considering them as one of the top 10 security risks.

In this post, we highlight some of the weaknesses potentially found in Drupal websites and how to resolve them so that your own organisation doesn’t become the next victim of an XSS attack.

Drupal XSS vulnerabilities

While Drupal's security is amongst the best among its CMS peers, it's fair to say that older versions of Drupal were not as resilient as the most recent versions, Drupal 9 & 10. Drupal 7 made it much easier for developers and inexperienced site administrators to accidentally introduce XSS vulnerabilities. Templates built on PHP were at risk, as developers didn’t always follow secure coding practices, which could e exploited as user input wasn’t correctly sanitised.

Even today, if your website is built on Drupal 9, it may be at higher risk of attack if you are using contributed or custom modules.

30% of web applications are vulnerable to XSS.(iii)

So, what are some of these vulnerabilities that could potentially creep into your Drupal site, and how might they be exploited by hackers? We look at some of the most common types of attacks below.

1. Stored (Persistent) Cross-Site Scripting

This is the most damaging type of XSS, where an attacker uses Stored XSS to inject malicious content, usually JavaScript code, into the target application. If there is no input validation, this malicious code is permanently stored by the target application.

For example, an attacker may enter a malicious script into a user input field such as a blog comment field or in a forum post.

When a user opens the affected web page in a browser, the XSS attack payload is served to their browser as part of the HTML code in the same that legitimate content would be. This means that users will end up executing the malicious script once the page is viewed in their browser.

Since this method only requires an initial action from the attacker and can compromise many visitors afterwards, this is the most dangerous and engaged type of cross-site scripting.

Other examples of stored cross-site scripting attacks include the profile fields such as your username or email, which are saved on the server and displayed on your account page.

2. Reflected XSS (Non-persistent XSS)

This is the most common type of XSS attack and occurs when the payload is part of the request sent to the web server. The HTTP response then includes the payload from the HTTP request.

To lure users into making a request, attackers will use phishing emails, malicious links, and other social engineering techniques to steal cookies and force the user to take a particular action, which is why this type of XSS attack is often used on social networks such as Facebook, Twitter, and Instagram.

A typical example of reflected cross-site scripting on a Drupal site is a module that is used for a custom search integration, where visitors send their search query to the server, and only they see the result.

Attackers typically send victims custom links that direct unsuspecting users toward a vulnerable page. From this page, they will then employ a variety of methods to trigger their attack.

3. DOM-Based XSS

This is a less common but much more advanced type of attack that can be carried out if the web application’s client-side scripts write data provided by the user to the Document Object Model (DOM) - an API interface which defines the structure of your HTML page. The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM.

A DOM-based XSS attack is often a client-side attack, and the malicious payload is never sent to the server. Web Application Firewalls (WAFs) and security engineers who analyse server logs will find it extremely difficult to identify because they will never even see the attack. DOM objects that are most often manipulated include the URL (document.URL), the anchor part of the URL (location.hash), and the Referrer (document.referrer).

An example of DOM-based cross-site scripting attack would be when the website changes the language selection from the default one to one provided in the URL.

Other types of XSS attacks

While the three outlined above are the most common types of XSS attack you’re likely to encounter, there are a couple of others that are also worth mentioning.

Self cross-site scripting occurs when attackers exploit a vulnerability that requires extremely specific context and manual changes. The only one who can be a victim is yourself. These changes might include cookie values or setting your own information to a payload.

An example of self cross-site scripting is running unverified code on social media platforms or online gaming where some reward or information is offered by running the code.

Hackers may also sometimes use blind cross-site scripting attacks, which occur when an attacker can’t see the result of their attack. Here, the vulnerability usually lies on a page that only authorised users can access.

However, this method requires more preparation for it to be successful: if the payload fails, the attacker won’t be notified.

Hackers will often use polyglots (multiple attacks used together as one piece of text or data) to try and increase the success rate of their attacks, which are designed to work in many different scenarios, such as in an attribute, as plain text, or in a script tag.

An example of a blind cross-site scripting attack is when a username is vulnerable to XSS, but only from an administrative page restricted to admin users.

How to prevent vulnerabilities on your Drupal website

Adaptive can help you assess whether your organisation’s Drupal website is vulnerable to XSS attacks and can help you fully secure your website with regular testing and maintenance.

Some of the ways in which you can kickstart your security efforts to combat XSS attacks include:

1. Make sure you patch all your modules

The simplest and safest way to ensure your Drupal website isn’t vulnerable to XSS is to not run modules with known cross-site vulnerabilities in them, in addition to patching all your modules to address any such security issues.

Adaptive can help you ensure all the modules installed on your Drupal website are patched regularly to reduce the risk of XSS attacks, along with other security services such as HTTP security headers hardening and Drupal-specific penetration testing.

2. Review your custom modules to ensure there is no XSS

If your Drupal site uses a custom module (i.e. one written by your Drupal developers) it should follow Drupal’s best practices for writing secure code which include using specific functions in your code to prevent XSS.

Any areas of your module that process user data (form input, files uploads etc.) should ensure that check functions are used where this data might be displayed to the user (e.g search terms entered by the user).

3. Configure text formats so that scripts are not allowed

Drupal's Input Formats are used on elements where a user may want to enter a variety of different types of text input. options typically include plain text, limited HTML tags (bold, headings, images etc.) or full HTML.

The default plain text format prevents all HTML and is safe for all text inputs as any HTML entered is converted to text. By default, the filtered HTML format is also safe, as only certain HTML tags are allowed, but you will want to check the allowed HTML tags don’t include the <script> tag which would allow XSS.

Full HTML which is completely unfiltered is unsafe to use for both anonymous or standard users as it would allow anyone with one of these roles to be susceptible to attack, e.g. if you allow anonymous commenting with "Full HTML" input format, a visitor could add an inappropriate image or malicious JavaScript code capable of changing your password on the site.

4. Add Drupal’s content security policy to your website

The Content Security Policy header allows your Drupal website to inform browsers of trusted sources for JavaScript, CSS, and other external resources.

This carries the benefit of an extra security layer that will detect and mitigate the risk of XSS attacks, data injection and other potential vulnerabilities.

Adaptive can install this on your Drupal site as an additional security barrier against hackers using XSS as a form of attack.

5. Use Twig templating

The introduction of Twig templating as a default in Drupal 8 and 9 has allowed site security administrators to separate the business layer of their website from the presentation layer. This has provided the crucial bonus of stopping UI developers from making mistakes in the core Drupal security model.

The Twig theme engine now auto-escapes everything by default. This means that every string printed from a Twig template is automatically sanitized if no filters are used. This sanitising of output will help you avoid XSS attacks, although to take full advantage of Twig’s functionality, all output should be outputted via Twig templates.

Conclusion

Although our suggestions above for protecting your website from XSS attacks are not exhaustive, these tips should at least provide you with a decent starting point. As technology continues to grow and change, attacks from hackers will become more advanced. However, by getting to grips with the basics and making sure your essential maintenance checks are covered, you will be prepared for any future attacks that are likely to occur.

The first step in your XSS defence should be to review all your current Drupal modules (both contrib and custom) and check they are patched/updated and not showing any signs of XSS vulnerabilities. After this, you can start looking at bolstering your site’s security further by configuring text formats, using twig templates, and adding in Drupal’s content security policy.

To be certain that your website remains secure against XSS (and other vulnerabilities), you should also run regular Penetration Tests against your website. Adaptive can provide regular Drupal-specific pen testing as part of our suite of cyber security services for Drupal

If your business needs a little extra help with implementing any of these steps, or you're looking for further security guidance for your Drupal website, please contact us today.

Sources:
(i) PreciseSecurity.com research, 2020
(ii) OWASP Top 10, 2021
(iii) PurpleSec, Cyber Security Trends Report, 2022