This page last changed on Sep 29, 2008 by smaddox.

As a public-facing web application, Confluence's application-level security is obviously important. This document answers a number of questions that commonly arise when customers ask us about the security of our product.

This document is for system administrators looking to evaluate the security of the Confluence web application. It does not address Confluence's internal security model (user/group management and content permissions), except as it relates to the overall application security. For information about user management, groups and permissions, please refer to the internal security overview.

On this page:

Error formatting macro: toc: java.lang.NullPointerException

Application Security Overview

Password Storage

When Confluence's internal user management is used, passwords are hashed through SHA1 before being stored in the database. There is no mechanism within Confluence to retrieve a user's password – when password recovery is performed, a new random password is generated and mailed to the user's registered address.

When external user management is enabled, password storage is delegated to the external system.

Buffer Overflows

Confluence is a 100% pure Java application with no native components. As such it is highly resistant to buffer overflow vulnerabilities – possible buffer overruns are limited to those that are bugs in the Java Runtime Environment itself.

SQL Injection

Confluence interacts with the database through the Hibernate Object-Relational mapper. Database queries are generated using standard APIs for parameter replacement rather than string concatenation. As such, Confluence is highly resistant to SQL injection attacks.

Script Injection

Confluence is a self-contained Java application and does not launch external processes. As such, it is highly resistant to script injection attacks.

Cross-Site Scripting

As a content-management system that allows user-generated content to be posted on the web, precautions have been taken within the application to prevent cross-site scripting attacks:

  • The wiki markup language in Confluence does not support dangerous HTML markup
  • Macros allowing the insertion of raw HTML are disabled by default
  • HTML uploaded as a file attachment is served with a content-type requesting the file be downloaded, rather than being displayed inline
  • Only system administrators can make HTML-level customisations of the application

When cross-site scripting vulnerabilities are found in the Confluence web application, we endeavour to fix them as quickly as possible.

Transport Layer Security

Confluence does not directly support SSL/TLS. Administrators who are concerned about transport-layer security should set up SSL/TLS at the level of the Java web application server, or the HTTP proxy in front of the Confluence application.

For more information on configuring Confluence for SSL, see: Adding SSL for Secure Logins and Page Security

Session Management

Confluence delegates session management to the Java application server in which it is deployed. We are not aware of any viable session-hijacking attacks against the Tomcat application server shipped with Confluence Standalone. If you are deploying Confluence in some other application server, you should ensure that it is not vulnerable to session hijacking.

Plugin Security

Administrators install third party plugins at their own risk. Plugins run in the same virtual machine as the Confluence server, and have access to the Java runtime environment, and the Confluence server API.

Administrators should always be aware of the source of the plugins they are installing, and whether they trust those plugins.

Administrator Trust Model

Confluence is written under the assumption that anyone given System Administrator privileges is trusted. System administrators are able, either directly or by installing plugins, to perform any operation that the Confluence application is capable of.

As with any application, you should not run Confluence as the root/Administrator user. If you want Confluence to listen on a privileged network port, you should set up port forwarding or proxying rather than run Confluence with additional privileges. The extra-careful may consider running Confluence inside a chroot jail.

Stack Traces

To help debug support cases and provide legendary support, Confluence provides stack traces through the web interface when an error occurs. These stack traces include information about what Confluence was doing at the time, and some information about your deployment server.

Only non-personal information is supplied such as operating system and version and Java version. With proper network security, this is not enough information to be considered dangerous. No usernames or passwords are included.

Finding and Reporting a Security Vulnerability

If you find a security bug in Confluence, please open an issue on http://jira.atlassian.com in the Confluence project.

  • Set the priority of the bug to 'Blocker'.
  • Provide as much information on reproducing the bug as possible.
  • Set the security level of the bug to 'Developer and Reporters only'.

All communication about the vulnerability should be performed through JIRA, so that we can keep track of the issue and get a patch out as soon as possible.

Publication of Confluence Security Advisories

When a security issue in Confluence is discovered and resolved, we will inform customers through the following mechanisms:

  • A security advisory will be posted on this page.
  • A copy of the advisory will be sent to the confluence-users and confluence-announce mailing-lists (subscribe here). These lists are mirrored on our forums.
  • If the person who reported the issue wants to publish an advisory through some other agency (for example, CERT), we'll assist in the production of that advisory, and link to it from our own.

Severity Levels

Atlassian security advisories include a severity level, rating the vulnerability as one of the following:

  • Critical
  • High
  • Moderate
  • Low

Below is a summary of the factors which we use to decide on the severity level, and the implications for your installation.

Severity Level: Critical

We classify a vulnerability as critical if most or all of the following are true:

  • Exploitation of the vulnerability results in root-level compromise of servers or infrastructure devices.
  • The information required in order to exploit the vulnerability, such as example code, is widely available to attackers.
  • Exploitation is usually straightforward, in the sense that the attacker does not need any special authentication credentials or knowledge about individual victims, and does not need to persuade a target user, for example via social engineering, into performing any special functions.
Severity Level: High

We give a high severity level to those vulnerabilities which have the potential to become critical, but have one or more mitigating factors that make exploitation less attractive to attackers.

For example, given a vulnerability which has many characteristics of the critical severity level, we would give it a level of high if any of the following are true:

  • The vulnerability is difficult to exploit.
  • Exploitation does not result in elevated privileges.
  • The pool of potential victims is very small.

Note: If the mitigating factor arises from a lack of technical details, the severity level would be elevated to critical if those details later became available. If your installation is mission-critical, you may want to treat this as a critical vulnerability.

Severity Level: Moderate

We give a moderate severity level to those vulnerabilities where the scales are slightly tipped in favour of the potential victim.

The following vulnerabilities are typically rated moderate:

  • Denial of service vulnerabilities, since they do not result in compromise of a target.
  • Exploits that require an attacker to reside on the same local network as the victim.
  • Vulnerabilities that affect only nonstandard configurations or obscure applications.
  • Vulnerabilities that require the attacker to manipulate individual victims via social engineering tactics.
  • Vulnerabilities where exploitation provides only very limited access.
Severity Level: Low

We give a low severity level to those vulnerabilities which by themselves have typically very little impact on an organisation's infrastructure.

Exploitation of such vulnerabilities usually requires local or physical system access. Exploitation may result in client-side privacy or denial of service issues and leakage of information about organisational structure, system configuration and versions, or network topology.

Original ranking compiled by the SANS Institute
Our vulnerability ranking is based on a scale originally published by the SANS Institute.

Our Patch Policy

When a security issue is discovered, we will endeavour to:

  • issue a new, fixed Confluence version as soon as possible
  • issue a patch to the current stable version of Confluence
  • issue patches for older versions of Confluence if feasible

Patches will generally be attached to the relevant JIRA issue.

Published Security Advisories

Related Server Security Pages
Java Policy Security with Confluence
Adding SSL for Secure Logins and Page Security
Click to see pages related to user and group permissions.
Document generated by Confluence on Dec 03, 2008 15:04