Joomla Security Team Sprint, Cologne, May 2018. I guess we all agree that it's one of Joomla's key priorities to offer a software that is as secure as possible, as this plays a crucial role in the user's experience running Joomla - a hacked user, is a very unhappy user.

Joomla always took security seriously by running a dedicated developer team, the Joomla Security Strike Team (JSST). This team, currently consisting of 14 members, has three main tasks:

1. Handle incoming security reports: triage reported issues, develop and test patches, communicate with reporters and other teams
2. Improve Joomla’s architectural security by pushing forward new security technologies
3. Actively look for issues in the codebase: by doing reviews of already existing or new parts of the code, we try to not only rely on external reports but also take an active role

In May 2018, the team had it’s very first in-person codesprint in Cologne, following the international J&Beyond conference. Besides some implicit team building that just naturally happened while spending time together, we also tackled 3 areas very specifically:

1. Prepared statements: Joomla has a rather unlucky track record in terms of SQL injection issues, mainly caused by the fact that the database API did not expose any possibility to use the well established technology of so called “prepared statements”. With Joomla 4 coming closer, we wanted to make sure that prepared statements finally make it into core.
2. Content-Security-Policy: the other main issues besides SQLI are the so called Cross-Site-Scripting issues (XSS). These are mainly caused by Joomla’s design, using plain PHP as templating engine and therefore relying on the developer to actively secure each and every user provided input before outputting it in the site’s markup. Content-Security-Policy (CSP) is a great way to massively reduce effects of potential XSS issues
3. Work on recently reported issues and previously known but complex to fix bugs

Prepared Statements

SQL injections allow attackers to pass their own database commands into a SQL query and thereby modifying the returned results (i.e. returning user password hashes instead of articles) or, even worse, modify content being written to the database, allowing i.e. overwriting a super admins password.

In the IT world there is a very well known and established technique to prevent such issues, the so called prepared statements. The basic idea is rather straightforward: instead of building on large query that consists of both, the actual commands and the content being used in them, we separate the query and the content from each other. Therefore, the database engine (i.e. MySQL) itself can apply any required filtering techniques on that content, guaranteeing that an attacker can not modify the surrounding commands. Under the hood this by the way also means that multiple calls to the database server are being made, transfering query and parameters separated from each other, the actual parsing and execution then happens within the engine and not in PHP.

So far, it was not possible to use prepared statements in Joomla for two main reasons:

1. We are using the mysql PHP driver that does not support prepared statements at all
2. The JDatabase API does not (or not consistently) implement prepared statements

In order to change this, Michael Babker did some tremendous work in the framework’s database package, bringing prepared statements with the unnamed parameter syntax to all drivers being used in Joomla 4. During our sprint, we added a mapping layer to also be able to use named parameters with the mysqli driver, resulting in consistent support for the easier to use named parameters in all drivers. On top of that, we tested the existing database-related PR’s that were open and started to convert the existing queries in the documentation to prepared statements.

Content-Security-Policy

Effectively fighting XSS issues in Joomla is rather complicated. Joomla uses PHP as it’s templating engine which is straightforward and has a lot advantages, but comes with one big downside: PHP does not escape output by default and therefore completely relies on the developer to escape (and thereby secure) the output accordingly. As we have thousands of places where output is being generated and all of this code has been written by humans, it’s a natural thing that developers forget to add the escaping, resulting in XSS issues.

To overcome this design problem, the JSST wants Joomla to be the very first major web application shipping with a default Content-Security-Policy being enabled by default. Content-Security-Policy (CSP) is a standard that allows web applications (like Joomla) to tell browsers which assets (Javascripts, Iframes, Fonts, Styles etc.) are allowed on a specific web page - and if a resource is not part of that whitelist, it will be automatically blocked by the browser, preventing i.e. the execution of malicious scripts.

In order to generate that mentioned whitelist we extended the core to automatically include assets to that list, if those assets have been added using the server side JDocument APIs. So, if you as a developer use the core APIs as you are supposed to do, your assets will automatically be considered in the CSP, allowing us to deny any other (potentially malicious) scripts in Joomla 4 by default, making a huge step forward towards more secure sites.

On top of that, JSST figured out an innovative way to troubleshoot and fix potential CSP-related problems in real-world sites: we want to implement a “fixing mode” (still a working title) using CSP’s report function and a specially crafted core component to automatically whitelist blocked resources by simply enabling the fixing mode and browsing the broken subpages as an administrator. This is an extremely user friendly way to fix such issues and takes away the complexity of this standard for an average user.

Tackling the list of open issues

In the weeks before the sprint, multiple non-critical issues had been reported to the team, those got patched and tested throughout the sprint and will be released in the coming Joomla version.

The JSST - Joomla’s strongest line of defense

During the 3 days of the sprint, the team was incredibly motivated, working through as many problems as humanly possible. I attend multiple sprints already but rarely experienced such a concentrated atmosphere. I literally had to force people to take a break to grab something to eat or just relax for 5 minutes, clearly showing great passion to make Joomla more secure than ever.

I’m extremely proud and thankful for this great team that I’m allowed to work with - and you as a Joomla user can be sure that your site’s security is in very good hands!