11 Sep 2015

Drupal has proven to be one of the very secure content management systems to work on and web security is indeed taken seriously by the Drupal community.

drupal security
But among the stakeholders who have not worked with Drupal in the past or have not had any Drupal implementations, we have observed that there are a certain set of queries and concerns which are inevitably common. Business owners, when evaluating the technology stack for an enterprise quality solution, always consider the web security of paramount importance and rightly so. 
Drupal addresses not only all the identified security threats but also has a robust mechanism to ensure that all the modules and code that goes into the Drupal project, may it be for Drupal core or for the contributed modules, undergoes strict security guidelines and if at all some security flaw is found, it is immediately taken care of by the Drupal Security Team, the process of which will be highlighted in paragraphs below.
Internationally, The Open Web Application Security Project (OWASP), an online community dedicated to web application security has been instrumental in laying out the guidelines for the web application security and hence focusing on improving security of the softwares’ worldwide. OWASP’s Top Ten Project has distinctly identified the following top 10 most critical web application security flaws and this is how Drupal handles each one of them.
Rank Name Details How Drupal Handles This
A1 Injection Injection flaws, such as SQL and OS 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. While creating a database query, Drupal’s object oriented database API ensures that all the query parameters are sanitized. Hence it is impossible to create any injection holes even erroneously because that would later anyways be handled by the database API. Also, Drupal’s File API ensures that all the file uploads and file write operations are managed in a safe manner ensuring that there are no dangerous files that potentially can be executed by the server.
A2 Broken Authentication and Session Management 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. Drupal has a robust authentication and session management because all the user accounts, authentication processes and sessions are managed by Drupal core itself. It is not possible for the user to be able to escalate authorization as the usernames, unique IDs, passwords, etc are all managed on the server. Moreover, all the passwords are salted and hashed using the Portable PHP Password Hashing Framework. Also, all the login logout sessions are destroyed.
A3 Cross Site Scripting (XSS) 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. Drupal ensures that all the user generated content is properly scrutinized before being displayed and hence potential flaws that might be present in the user’s content are filtered out. For developers, Drupal has various API functions such as filter_xss(), check_plain(), etc for filtering output that ensure the prevention form XSS attacks.
A4 Insecure Direct Object References 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. Drupal does provides direct object reference but these are mostly built in such a way that they do not disclose direct system information. Drupal has a robust permissions and access system which prevents any unauthorized access. There are various obfuscation methods contributed by the community. 
A5 Security Misconfiguration 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. Constantly the critical risks are evaluated and if some inefficiency is reported it is immediately taken care of by the Drupal Security Team and future releases are rolled out with the fix. Most of the critical risks such as admin site controls, text formats, etc are available only to the super admin. Comprehensive documentation for secure configuration is available and is updated regularly by the community.
A6 Sensitive Data Exposure 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. The user account passwords are salted and hashed based on algorithms of PHP Password Hashing Framework. The code contribution process and various checks that have been implemented ensures that the sensitive data is encrypted.
A7 Missing Function Level Access Control 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. Drupal has a rich permissions and authentication system and hence the Function level access is protected by the permissions system. URL access checking is tightly integrated into the entire menu-rendering and routing system.
A8 Cross Site Request Forgery (CSRF) 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. Mostly, the insecure actions or scripts are planted to the victim’s browser through HTTP POST method. Drupal's Form API neatly handles this by implementing unique form tokens. Drupal’s Form API protects against these attacks by inserting a token in every form. Hence during rendering any URL a confirmation with the Form API is asked whether the unique token is present and is also validated on the response handling. This easily protects against CSRF in POST requests. 
A9 Using Components with Known Vulnerabilities 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. All the libraries and frameworks that are included in the Drupal core are system level and go through multiple layers of security checks before going into the core and hence is of minimal risk to server or application compromise.  Also, there is a constant and consistent check for security which is performed even after a Drupal version is released, which allows Drupal.org to release Security patches or Major Security releases for Drupal core as soon as any vulnerability is detected.
A10 Unvalidated Redirects and Forwards 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. Internal page redirects in any case cannot bypass the Drupal's integrated menu and access control system. Drupal protects against automatic redirection to off-site URLs. This protects against potential phishing attacks.

Drupal Security Team and the Issue Handling Process.

Ensuring the security of a software project is an ongoing process. Drupal community takes security seriously, this can be highlighted by the fact that a separate dedicated Security team has been into existence since as early as 2005. Drupal has been one of the first CMS projects to have a dedicated Security team. 
Drupal Security Team is responsible for assuring the security of the modules that get listed on drupal.org. This team also ensures that the Drupal core remains robust and secure. Drupal interacts with the deployment stack of LAMP (Linux, Apache, MySQL, PHP) so it is important that the security is ensured among all the communications that happen among Drupal and the LAMP stack as well so there is no vulnerability that has not already been taken care of.
Drupal Security Team has been actively assisting in the security threats in Drupal core, contributed and plug-in modules and over a period of time a process has been formulated to ensure that security loopholes do not go unnoticed and if at all any flaw has been reported, it proactively handled. The process of handling the security flaw has been explained below.
  • The bug or the security issue can be highlighted by anyone. Drupal follows a standard simple process through which one can easily report the vulnerability. (https://www.drupal.org/node/101494 )
  • The Drupal security team reviews and validates the security issue. It also evaluates the potential impact on all supported Drupal releases.
  • If the issue is found to be valid, the maintainer of the module is notified about it for elimination of the issue.
  • Once the maintainer has fixed the issue, the Security Team then helps in discussing, testing and reviewing the fix. This process goes on till the fix is not reviewed and accepted.
  • Then, the new versions, code patches are created and tested to ensure that these patches do not create any other issues or vulnerabilities.
  • The new fixed versions are now made available on drupal.org.
  • The new versions are then deployed to all the sites by the update route.