Anything you can do, XSS can do better

Issue

Cross-site scripting (XSS) is the number-one vulnerability in Drupal code, and can be one of the scariest forms of exploitation, because anything you can do, XSS can do better. Note that this doesn't mean that the JavaScript that the XSS uses can do things that you can't do — but it can certainly make changes to your site faster than you can.

XSS is the number-one vulnerability in Drupal code based on the times reported in Drupal core and the contributed project Security Advisories, as published by the Drupal Security team.

Resolution

Demonstrating the problem

During XSS demos and vulnerability testing, it's easy to use some code like alert('xss') to cause JavaScript to be executed where it shouldn't — but an alert box isn't scary.

It's scary when JavaScript can put your Drupal site offline. And it's even more frightening when it locks you out of signing back in because it changed your administrator account username, password, and email address. The following short video includes a demonstration of what's possible.

To sum up, the malicious JavaScript entered by the attacker, when unknowingly executed by an administrator, affected the website in the following ways:

• Changed the site title and site email address.
• Changed the administrator's username, email, and password.
• Set a site-offline message and put the site in offline status.
• And finally, signed the current user out of the site. The final piece of the attack by the JavaScript is actually a different class of attack known as cross-site request forgery (CSRF).

Protecting against XSS

The most effective method to protect against cross-site scripting is to disable the use of the Full HTML input format by anonymous users. In general, you should understand how to configure your site securely and know what actions you allow untrusted users to perform.

Note that Drupal does not come by default with Full HTML enabled for anonymous users.

Be mindful of contributed modules

It's also common that contributed modules print user-supplied data insecurely, which can make the site more vulnerable for an XSS attack. Popular modules are often more vetted and secure, and thus safer to use. Also, if you're developing your own code, be sure that you're correctly using the APIs and following best practices .