The Drupal community puts a lot of attention into security. Drupal’s security team is the main party that is dealing with security issues and reports. They are monitoring all modules with stable releases that are published on drupal.org. This is one of the many reasons why we strongly recommend all our clients to publish their custom modules or 3rd integration plugins through it.
Another way of ensuring high security standards are APIs that automatically ensure security when used correctly and a set of best practices that should be followed in order to write secure code. The Relevant section of the Drupal 8 documentation provides more information on that. The similar document for Drupal 7 is also relevant, since a lot of things stayed the same since then.
MD Systems is strictly following all recommendations and best practices that the community developed. Even more, since we are one of the biggest contributors in the Drupal community we’re actively taking part in their further development and advancements. We are also using automated tools that can detect some of the security vulnerabilities in the code.
In this series of blog posts we’ll explain some of the most common vulnerabilities on the web and how Drupal secures against them. This time we’re covering XSS, which is probably the most common vulnerability on the internet.
Cross Site Scripting (XSS)
Cross site scripting allows attackers to inject a custom code (usually JavaScript) into a 3rd party site which is then executed on behalf of other users. This allows them to potentially bypass access controls.
Drupal’s general approach to the unsecure user-submitted content is escaping at the display time. This means that we generally consider any content that came from the internal database or from any 3rd party system as potentially malicious.
Drupal 7 relied on developers to properly escape the content before displaying them (using functions like check_plain() and filter_xss()). Useful and easy to use API functions made writing secure code easy, but still prone to human errors.
Drupal 8 made a huge step forward in this areas. In order to secure the system against XSS it automatically escapes all variables that are printed as part of the Twig-powered template system. This means that we’re providing substantial protection against XSS attacks by correctly using provided render APIs.
Example
A naughty content author would like to gain editorial privileges to be able to bypass editorial decisions. He creates an article with some malicious JavascriptCode injected into it. OK, … in real life something a bit more sophisticated than a simple alert() would be needed, but it will work for the sake of the presentation.
Our naughty editor now expects an alert popup to appear when the article is visited. But Drupal 8 is smarter. It escapes the malicious code which results in it being displayed to the entire universe. Not pretty, but definitely secure. The bad intentions of our naughty content author are immediately revealed.
Drupal: 1, Hackers: 0
That’s it for today. Next time we’ll see how Drupal deals with SQL injection attacks. Follow us on Twitter to stay tuned!
Do you need security review of your Drupal site or module? Get in touch!