Confluence Docs 2.10 : Confluence Security
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.
On this page: Error formatting macro: toc: java.lang.NullPointerException
Application Security OverviewPassword StorageWhen 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 OverflowsConfluence 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 InjectionConfluence 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 InjectionConfluence is a self-contained Java application and does not launch external processes. As such, it is highly resistant to script injection attacks. Cross-Site ScriptingAs 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:
When cross-site scripting vulnerabilities are found in the Confluence web application, we endeavour to fix them as quickly as possible. Transport Layer SecurityConfluence 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 ManagementConfluence 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 SecurityAdministrators 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 ModelConfluence 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 TracesTo 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 VulnerabilityIf you find a security bug in Confluence, please open an issue on http://jira.atlassian.com in the Confluence project.
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 AdvisoriesWhen a security issue in Confluence is discovered and resolved, we will inform customers through the following mechanisms:
Severity LevelsAtlassian security advisories include a severity level, rating the vulnerability as one of the following:
Below is a summary of the factors which we use to decide on the severity level, and the implications for your installation. Severity Level: CriticalWe classify a vulnerability as critical if most or all of the following are true:
Severity Level: HighWe 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:
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: ModerateWe 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:
Severity Level: LowWe 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.
Our Patch PolicyWhen a security issue is discovered, we will endeavour to:
Patches will generally be attached to the relevant JIRA issue. Published Security Advisories
Related Server Security Pages
![]() |
![]() |
Document generated by Confluence on Dec 03, 2008 15:04 |