This page explains how we ensure that Magnolia is a secure platform for your project.
Magnolia is only as secure as your project implementation
There is no single certificate that would validate a Web application as secure. Magnolia is a platform, which means security depends on the environment Magnolia is deployed in and on your project-specific implementation.
Only you know the specifics of your environment and your business. For any given application, there may not be a threat agent that can perform the relevant attack, or the technical impact may not make any difference to your business. Therefore, you should evaluate each risk for yourself, focusing on the threat agents, security controls, and business impacts in your enterprise. – Open Web Application Security Project (OWASP)
OWASP Top 10 security risks
OWASP Top 10 is a list of critical web application security risks. While there is no certificate that could certify the Magnolia platform as secure, OWASP Top 10 is a very reasonable checklist. It's a good idea to validate your project implementation against the Top 10.
Rank
Risk
A1
Magnolia is inherently protected against OS and SQL injections by not using a direct access to the OS or database in any way. All access to database and OS data is handled via JCR APIs.
However Magnolia allows the implementor of a solution on top of Magnolia to use custom queries for SQL-like JCR search. The implementor is fully responsible for making sure that such custom queries can't be used by an attacker for injection.
A2
In order to make security configurable and allow integration with external security systems, Magnolia's security implementation is based on the Java Authentication and Authorization Service (JAAS) standard. The configuration of the JAAS login chain and implementation of JAAS modules provided by Magnolia are secure and handle user security correctly. However, it is the responsibility of the implementor to ensure that their custom configuration also behaves correctly and that by changing configuration they do not allow any insecure access.
A3
All templates provided by Magnolia are continuously checked and improved to prevent any such attacks. In case of discovering any such vulnerability Magnolia is fully committed to providing a fix immediately. The in-place templating functionality in Magnolia allows the client to apply a patch for the issue in a quick and easy manner to help protect their site. By default, Magnolia wraps all content nodes to prevent malicious input entered also by users who have access to the system such as an editor with malicious intent. However, since implementors often introduce custom templates with special functionality, it is the responsibility of the implementor to ensure that all such modifications are still safe from XSS.
A4
Magnolia doesn't expose any database objects, all database access is handled over the JCR API, nor any file object for direct user manipulation.
A5
Magnolia delivers secure rather than insecure default configuration. Active action from implementor is required to make configuration insecure.
A6
The only sensitive data used by Magnolia is user credentials. Those are either not stored in Magnolia at all but rather in LDAP/AD/custom security or when stored, Magnolia stores only a hash of such information. The hash itself is generated with slow hashing functions with additional complexity to prevent brute force, rainbow and other forms of attacks.
When storing sensitive additional data, the implementor has to ensure encryption of such data. Magnolia provides cryptographic libraries out of the box to make such a task as simple as possible.
A7
Magnolia security is based on node access, reading the data itself. Permissions are checked on every access to the data.
A8
Session management is handled by the application server that Magnolia is deployed on, not by Magnolia itself.
A9
Magnolia is not aware of any vulnerabilities in the libraries used in the product at the moment. If at any point such a vulnerability is discovered, Magnolia immediately upgrades to a newer version of the library to avoid the issue or provides a workaround to be applied on top of the library to prevent an exploit.
A10
Out of the box Magnolia doesn't forward any requests to other sites. When configuring such a functionality in Magnolia, the implementor is fully responsible for preventing abuse of such features.
How to report vulnerabilities
If you find a security vulnerability in Magnolia, please report it privately:
Our goal is to keep the vulnerability private. Issues in the SUPPORT project are private to Magnolia and the issue reporter.
How we react to vulnerability reports
Magnolia evaluates whether the vulnerability is real or a case of misconfiguration. If real, we commit to provide a fix in 30 days.
Magnolia creates separate JIRA issues for the fix. These issues are visible to Magnolia only.
When a fix is available, Magnolia informs the reporter through the same channel where the issue was reported and provides the fix.
Magnolia makes the fix available to all clients in the next maintenance release. We make a short statement about the fix in release notes but give no details since unpatched installations are vulnerable.
JIRA issues for the fix remain private for 90 days after the fix is released. This shelters clients from exposure and prevents anyone from exploiting the vulnerability.
How to learn about security fixes
Read the release notes carefully. Security fixes are announced in release notes.
All currently maintained Magnolia branches get security fixes backported if the branch is vulnerable. For example, if a vulnerability is reported in Magnolia 5.4 we backport the fix to Magnolia 5.3.
Maintenance releases for the current major version are available for the Community Edition as well as the Enterprise Edition.
Maintenance releases for previous major versions of Magnolia are available to Enterprise customers only (i.e. customers that have an active subscription to Magnolia Enterprise Edition).