Preventing Security Attacks

Still need help?

The Atlassian Community is here for you.

Ask the community

This page provides guidelines which, to the best of our knowledge, will help prevent security attacks on your JIRA installation.

Use Strong Passwords

Administrators should use Strong Passwords

All your JIRA administrators, JIRA system administrators and administrators of all Atlassian products should have strong passwords. Ask your administrators to update their passwords to strong passwords.

Do not use passwords that are dictionary words. Use mixed-case letters, numbers and symbols for your administrator passwords and make sure they are sufficiently long (e.g. 14 characters). We encourage you to refer to the Strong Password Generator for guidelines on selecting passwords.

Using strong passwords greatly increases the time required by an attacker to retrieve your passwords by brute force, making such an attack impractical.

Administrators should have Different Passwords for Different Systems

As well as choosing a strong password, administrators should have different strong passwords for different systems.

This will reduce the impact the attacker can have if they do manage to obtain administrator credentials on one of your systems.

Apply JIRA Security Patches

Apply the patches found in any security advisories that we release for your version of JIRA.

These patches protect JIRA from recently detected privilege escalation and XSS vulnerabilities.

Protect Against Brute Force Attack

You can also actively protect your systems against repeated unsuccessful login attempts, known as "brute force" login attacks.

Enable Brute Force Login Protection on your Web Server

It is possible to also enable brute force login protection on your web server by detecting repeated authentication failures in application logs. Once repeated login failures have been detected, you can set up an automated system to ban access to your web server from that particular IP address.

For more information on how to configure an automated approach to this kind of login prevention, refer to Using Fail2Ban to limit login attempts.

Restrict Network Access to Administrative Sections of Applications

An Atlassian application's administration interface is a critical part of the application; anyone with access to it can potentially compromise not only the application instance but the entire machine. As well as limiting access to only users who really need it, and using strong passwords, you should consider limiting access to it to certain machines on the network.

For more information on how to implement Apache blocking rules to restrict access to administrative or sensitive actions in:

You can use a similar approach to protecting all Atlassian applications.

Restrict File System Access by the Application Server

The application server (e.g. Tomcat) runs as a process on the system. This process is run by a particular user and inherits the file system rights of that particular user. By restricting the directories that can be written to by the application server user, you can limit unnecessary exposure of your file system to the application.

For example, ensure that only the following directories can be written to by JIRA's application server:

For detailed instructions, please see Tomcat security best practices.

Disable Jelly

Jelly is disabled in JIRA by default. If you need to use Jelly, you should enable it immediately prior to use and disable it immediately afterwards. See the JIRA Jelly Tags documentation for details.

On this page:

 

Configuring Tomcat to use HttpOnly Session ID Cookies

'Recommended' (formerly Standalone) distributions of JIRA from version 4.1.2 enforce the HttpOnly flag on session ID cookies by default, as a means to minimise the risk of common XSS attacks. For more information about this feature, please refer to the JIRA Security Advisory 2010-06-18.

If you are running the JIRA WAR distribution on Tomcat (version 5.5.27+ or another application server that is unsupported), it is likely that JIRA's session ID cookies will not be transmitted with the HttpOnly flag. Hence, to mitigate the risk of common XSS attacks, we recommend that you configure your application server to transmit HttpOnly session ID cookies.

To configure your JIRA WAR distribution running on Tomcat to use HttpOnly Session ID Cookies:

  1. Shutdown the JIRA service running on Tomcat and the Tomcat application server.
  2. Open the context.xml file of the Tomcat installation running JIRA in a text editor.
    (info) This file is typically located in the conf subdirectory of the main Tomcat installation directory.
  3. Add the following Manager element within the Contextelement of this file:

    ...
    <Context>
      ...
      <Manager useHttpOnly="true"/>
      ...
    </Context>
    ...
    

    (info) To disable HttpOnly Session ID cookies, either remove this Manager element or change the value of its useHttpOnly parameter to false.

  4. Save your changes to the context.xml file and restart JIRA.

See Also

If you suspect that your publicly accessible JIRA installation has been compromised by a security attack, please refer to our detection guide for more information on how to identify signs of attack.

Last modified on Apr 16, 2013

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.