Drupal and the top-10 of security flaws

In the realm of security Drupal has a great reputation. Asked why, Drupal experts can often be heard stating that ‘Drupal is secure by design’, meaning that from the ground up Drupal was built with the notion in mind that the system should be safe and secure.

OWASP, the world-wide software security platform and an organization with strong authority, annually issues a Top-10 of the most critical web application security flaws. This Top-10 is widely accepted as one of the most important insights in the state of software and internet security.

Dries Buytaert, Drupal’s sole founding father, claims that Drupal -being secure by design- obviates all of OWASP’s top-10 of security problems. In the following overview -which for the most part was compiled from drupalsecurityreport.org and the OWASP Top Ten Project, the top-10 is listed, explained and point by point annotated with Drupal’s claims as to how Drupal addresses the issue.

1. Injection

What is it?
Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

How does Drupal handle it?
Drupal contains a robust object-oriented database API that makes it difficult for developers to unknowingly create injection holes by automatically sanitizing query parameters and enforcing an interface.

2. Broken Authentication and Session Management

What is it?
Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.

How does Drupal handle it?
User accounts and authentication are managed by Drupal core. Authentication cookies and a user's name, ID, and password are managed on the server to prevent a user from easily escalating authorization. User passwords are salted and hashed using an algorithm based on the Portable PHP Password Hashing Framework and existing sessions are destroyed upon login and logout

3. Cross-Site Scripting (XSS)

What is it?
XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

How does Drupal handle it?
Drupal has a strong system for filtering user-generated content on display. Untrusted user's content is filtered to remove dangerous elements by default. For developers, Drupal has at least eight API functions for filtering output to prevent XSS attacks.

4. Insecure Direct Object References

What is it?
A direct object reference occurs when a developer exposes a reference to an internal  implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.

How does Drupal handle it?
Drupal's rich permissions and access control system prevent unauthorized requests. Methods for obfuscation are available through configuration and community-contributed code. Further, validation and protection against semantic forgery attacks is implemented in Drupal core via the Form API.

5. Security Misconfiguration

What is it?
Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

How does Drupal handle it?
Many critical risks, such as access to administrative site controls, text formats, and private information are restricted to a single admin account by default. Identified design inefficiencies that lead to misconfiguration are corrected often through usability testing and fixes are recommended for inclusion to core. Documentation of best practices for secure configuration and site building are provided for free on drupal.org and there are several contributed projects that conduct automated security review or implement further secure configurations.

6. Sensitive Data Exposure

What is it?
Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

How does Drupal handle it?
Account passwords are salted and repeatedly hashed based on the Portable PHP Password Hashing Framework. Available Drupal community-contributed code offer solutions to encrypt sensitive data at rest or in transit.

7. Missing Function Level Access Control

What is it?
Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.

How does Drupal handle it?
Function level access in Drupal is protected by a powerful permission-based system which checks for proper authorization before the action is taken. For the case of URL access, access checking is tightly-integrated into the entire menu-rendering and routing system which means that visibility of navigation links and pages are protected by the same system that handles incoming requests.

8. Cross-Site Request Forgery (CSRF)

What is it?
A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

How does Drupal handle it?
Drupal validates user intention in actions using industry standard techniques. Typical actions with side-effects (such as actions that delete database objects) are generally conducted with the HTTP POST method. Drupal's Form API implements unique form tokens to protect against CSRF in POST requests. Less important actions can leverage the one-time token generation and validation functions of the Form API while still using an HTTP GET request.

9. Using Components with Known Vulnerabilities

What is it?
Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.

How does Drupal handle it?
Included libraries and frameworks (of which there are few) in Drupal core are system-level, unsophisticated, and of low risk to full server or application compromise.

10. Unvalidated Redirects and Forwards

What is it?
Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

How does Drupal handle it?
Internal page redirects cannot be used to circumvent Drupal's integrated menu and access control system. Drupal protects against automatic redirection to off-site URLs which could be used in a phishing attack.