System-specific Security for JIRA and Confluence - Security around Atlassian Systems, Part 2

Montag, 03. April 2017, 13:53 Uhr

In this article we talk about specifics about JIRA and Confluence configuration and system management: aspects that have to be configured by administrators and guidelines to be followed by project-administrators, space-administrators and users. Those guidelines need regular monitoring and communication with your project- and space-administrators or specific users.

JIRA Configuration

The most important topics on JIRA configuration are

  • Shared filters and dashboards → all users
  • Long running JQLs → all users
  • Proper definition of permissions → Administrators only

Apart from these topics there may occur some very specific problems we could not discuss here. But if you follow the recommendations around the usage of groups and permissions most problems should not occur.

Shared filters and dashboards

JIRA allows users to share filters and dashboards with specific user groups, project roles or everyone. While the first two options will unlikely cause any problems, the last option could cause a lot of problems.

If you have shared your dashboard or filter with everyone, there are two effects you have to have in mind:

  • Any user who searches for a specific filter for gadgets or any other purpose will see all the filters in his list.
  • Anonymous users can see your filter.

Apart from the problem of flooding the list of accessible filters for all your colleagues – imagine a list with 1,386 filters from which only 7 are your filters – the main security concern here is that e.g. one customer could find filters defined for a project from another customer and is able to have a look at the filter query. This will at least give him some insights into which kind of issues and fields are used in the project and are important for you and the other customer. The same is valid for anonymous users.

The first option to handle the shared filters and dashboards is to regularly review the shared items in your JIRA Administration (Managing shared filters, Managing shared dashboards) and talk to all the users who have shared filters or dashboards with everyone and ask them to restrict it at least to a group or a project role.

NOTE: Customize or extend Atlassian software

The next two options include steps to customize or extend Atlassian software (adding/changing CSS rules, HTML, JavaScript, etc.). As the Atlassian Support Offerings states, the support does not include customizations made to Atlassian products. Be aware that this material is provided for your information only and using it is your risk.

The second option is to restrict the access for anonymous users, so that they cannot access the shared filters of your system. In order to do this you have to edit the configuration-file actions.xml on your installation directory, so be sure you know what you do and be aware that your changes have to be done again after each update. We will not describe how to do this as it is not covered by the support from Atlassian.

The third option is to simply remove the “everyone” option from the drop-down-list if you share a filter or dashboard. The problem here is that you have to use JavaScript in your announcement banner to make this work. Again, we will not describe how to do this as it is not covered by the support from Atlassian.

INFO: New Feature
As of JIRA 7.2 you are able to select “Any logged-in user” to share filters and dashboards.

Slow JQL Requests

Another topic which could be important is the slow JQL requests. At first glance this is hardly a security topic, but if you have a lot of advanced users who create really complex JQL request that run up to 20 minutes and longer it could become one. At this time the JQL request will still be executed even if the browser already got a time-out. In most cases the users simply fire the JQL request a second and third time which will result in a stack of slow JQL requests which could cause performance problems in extreme cases if you are not aware of it and try to prevent the executions of such queries in the first place.

The problem also could occur if projects grow and queries will be extended over multiple projects. At first the queries are fast and will be included in Dashboards and Confluence pages, but in the long term the queries become slow and affect your systems performance in extreme cases.

As you cannot prevent the creation of slow JQL requests, you have to monitor whether they occur. Therefore you can use the slow query log, which is enabled by default. Your system administrator will find it within the log directory "/var/atlassian/application-data/jira/log/atlassian-jira-slow-queries.log". Here all JQL requests will be logged which take more than 400ms. You can review the logs and contact users who performed slow JQL requests and help them to optimize the JQL requests or divide it into multiple JQL requests.

INFO: Learn more about JQL and Logging
If the log is not shown, you can enable it as described here: How to Enable Detailed JQL Logging in JIRA.

The following documentation explains how to optimize the JQLs of your users:

Proper definition of Permissions

The definition of permissions is important throughout the whole configuration process – especially for JIRA – from the basic setup to the configuration of specific workflow steps. The proper definition is based on the following principles:

  • Create as many roles as necessary, and as few as possible
  • Use only those roles in your permission schemes
  • Use a set of standard user-groups for each project or team

The first step should always be to create a set of roles which reflect your needs in different permissions. This could be a simple set with 3 roles (project administrator, developer, view-only) or reflect your development method (project administrator, product owner, Scrum master, team, view-only) or reflect your organization (project administrator, project manager, team lead, developer, quality assurance, technical writer, freelancer, external partner, customer). Whatever you use, discuss all options and choose the one that fits your needs and use it for all projects. If you need more complex role definitions you can try to separate the roles in the following categories:

  • Project Permissions:
    All roles here will guarantee access to the project and different permissions for each role e.g. project administrators, development team, read only, external users and so on. All users have to be part of one role here as only those roles will permit to see the project and perform different actions.
  • Workflow Permissions :
    All roles here will guarantee the possibility to perform specific transitions and actions based on a workflow configuration. Make sure those roles are not used in a permission scheme but only in workflow configuration. Here you can permit single users to e.g. use shortcuts in your process or perform restricted actions as e.g. “order feature”, “reject story” or similar transitions.
  • Additional Permissions:
    Those roles will guarantee specific permissions, e.g. the “planning permission”, “delete issue permission” or the “change reporter permission”. They are roles which can be assigned to specific users in addition to the project role to help to keep the project and issues clean or to support project managers, team leads or product owners.

The second step is to use only those roles in your permission scheme. The only additional roles you could use are the system-roles “reporter” and “assignee”. In this way you have a clear and understandable permission concept which is flexible enough to allow projects to permit users to their project as they wish within the frame you have defined.

INFO: Focus on one approach

Don’t try to use different approaches for different projects since roles are global. This will result in the fact that your project administrators can assign users to roles which will have no permission in the given project. As an example, imagine you have configured two approaches:

  • Scrum-Roles: project administrator, product owner, Scrum master, team, view-only
  • Organization: project administrator, project manager, team lead, developer, quality assurance, freelancer

For each approach you have also designed a permission scheme. Now all the roles will appear in the project administration. If a project administrator assigns someone to the “team lead” role within a Scrum project, this user will have no permission at all, as the role is not used in the permission scheme of this project. It could create a lot of discussion untill everybody understands the how and why of this implementation. In the worst case everybody ends up in the project administrator role, as this is the only role which works for everybody.

As an additional extension you can implement default user groups for your projects or teams. In this way they can simply assign the given groups to the roles for multiple projects and manage the permission for more than one project simply via the groups. If you have defined the same user directory in JIRA and Confluence you can also guarantee the correct permission for single users for JIRA and Confluence at the same time. Simply use the same groups to manage access to a project space and to the JIRA project. Now you have to simply assign a new user to the given groups and he has the correct permission in both systems. This will reduce the need of assigning specific permission to a bunch of single users, which could cause different problems over time and could lead to security problems – e.g. users who should not see tickets or pages are assigned to the wrong role in JIRA or have the wrong permissions in Confluence.

INFO: Train your administrators

Make sure that your system administrators and project / space administrators know the concept of your groups, roles and permissions. They are the people who define the roles and permit them to specific actions within the permission scheme, add users to groups, add groups to roles within specific projects and they have to discuss with users, why or why not they can perform certain actions.
We recommend to perform specific introductions and trainings for project and space administrators in order to learn the concept you have implemented and know how to use it properly.

NOTE: Permission for Anyone

We don’t recommend to allow anonymous access to your project as in this case also not-logged in user can see your project and all issues in it.

However, in some cases you maybe like to give anonymous users access to your project, in this case you or your JIRA-Administrator have to be aware of the following permission in your permission scheme:

  • Browse Project: In general all users who should be able to see your project have to have this permission. If you permit the group “anyone” here, you have enabled anonymous access to your project.
  • Create Issues: If you permit the group “anyone” here, anonymous user can create issues. Here you have to be aware of the fields “Reporter” and “Assignee” as well as the permission “Assign Issues”.
    • If the reporter is required an anonymous user cannot create an issue as a reporter have to be a valid user, but the anonymous user can see the create screen with all values of drop down fields and so on.
    • If the assignee is required and the anonymous user have not the permission “Assigne Issues” he could also not create an issues but see the create screen.

So here you need to make the reporter and assignee as optional in your field configuration as well as give the group “anyone” the permission “Browse Project”, “Create Issues” and “Assigne Issues” to be sure everything works as expected.

Confluence Configuration

As Confluence is more content-related than JIRA, you have to be aware of some other aspects here. The most important topics are:

  • Restricting the use and need of attachments
  • Don’t enable HTML-macros
  • Proper definition of permissions
  • Wiki gardening for space administrators

You have to be aware of additional aspects depending on the plugins you use and the usage of different restriction possibilities for users – especially regarding “page restrictions”. It depends on your permission management and other concepts. Here we will focus on the four topics given above.

Restricting the use and need of attachments

If your organization is new in the Confluence world, you will find that most users will simply upload document-files to the system. This could cause the following problems:

  • fast growing demand of storage space.
  • security risks based on embedded code in attached files
  • security risks based on attached files

The first option you have here is to simply restrict the size and file type your user can attach to any page. You can configure the attachment size as described here. This way you can handle the growing demand for storage space, as each version of a file will be saved as an old attachment version. This configuration should be discussed and defined as needed anyway, but it will not prevent the possibility to attach malicious files on your system.

The next option is to restrict the attachable file types in the first place. As this is not possible with simple configurations, you have to install the Attachment Filter for Confluence plugin. With this plugin you can specify which file types you accept as attachments and which not. Confluence does not execute code in files by default, so you have to find most common files in your organization which could cause harm. There is a risk for example based on malicious office files which will be “edited in Office” outside of the system.

If you have restricted the possibility to add attachments to your Confluence, the need of some specific functions from files as e.g. MS Visio, MS PowerPoint or MS Excel cannot be solved by Confluence itself. Therefore, if necessary, you need more plugins to give your users the possibility to create diagrams, charts or advanced tables with calculations and so on.

NOTE: Possible plugins to substitute Office files

At the time of writing there are a lot of plugins on the Atlassian Marketplace that should solve your needs more or less. We have evaluated some plugins and list those here, which will probably solve your needs best in our point of view. Nonetheless, there are a lot more possible solutions for you, so this is only a point to start.

  • Diagrams, UMLs and Flowcharts
    • Draw.io Diagrams for Confluence
    • Gliffy Diagrams for Confluence
    • Confluence Diagramming by Creately
    • Lucidchart for Confluence
  • Spreadsheets and Tables
    • Spreadsheets for Confluence
    • Excellentable Spreadsheet for Confluence

Don’t enable HTML-macros

As mentioned in the first part of this blog series, Confluence is resistant against cross-site scripting. But if you enable the HTML-macro, which is disabled by default, you give users the chance to attack your system from the inside. We recommend to disable or don’t enable the HTML-macro in the first place – especially if you have enabled anonymous users.

If your users already use the HTML-macro for some reasons and you like to disable it, you can simply rebuild the HTML content from your users with a user-macro within the confluence administration or you can simply migrate the content to a Confluence page via the HTML-import.

Proper definition of permissions

In Confluence your space administrators have to be aware of the space permissions even more than in JIRA. While in JIRA you have the possibility to define roles, in Confluence a space admin has to assign specific permissions to each user or group who should get access to a space. This will result in a wide range of permissions for different users within one space or over your whole system.

To ease the work of your space admins, we recommend to implement standard groups for your systems, as described above. In this way, you can simply define the permission for all the groups you have once and then just add new users to those groups.

A content-related problem could be the delete permission. A space administrator can restore a page from the trash. But deleted comments are gone for good. So here you should think about who should have those permissions. The permission to delete comments should only be assigned to space administrators in our opinion. The permission to delete comments includes all comments, not only your own, so in this way a user can simply delete important comments from others, which is a security risk without any question. Here the permission “delete own”, which is available since Confluence 5.10., will solve those problems. With this permission users are able to delete the pages, attachments or blogposts they have created, no matter if they are restricted in any other way.

Another problem could occur if you allow your users to restrict pages. At this time there are two possible restrictions you can define for a page. The first one is the edit restriction. Here, only the listed users can edit the page, while all others can view the page. The second one is the view restriction. Here, only the listed users can view the current page including all following pages. The edit restriction is only valid for the current page and will not be inherited. The view restriction is inherited to all child-pages down to the last level. So if a user restricts a top-level page he can restrict the whole space or large parts of it. We will give you an example to illustrate that.

Restrictions in Page Hierarchy

Have a look at the example hierarchy above. We will now describe some scenarios to give you an idea about which problems could occur.

1.) If a user adds a view restriction to the Home Page at the first level, only the permitted users will see the whole space content, no matter if they have proper space permissions or not. So even if you are permitted to see the space, you cannot see the contents of the space. If something like this occurs the first time it could be quite challenging to find out why users can see the space, but not the contents.

2.) If the Project Page is restricted to the team and a user likes to give a specialist access just to the page “Concept One” and make sure the expert will not see “Concept Two”, he has to restrict the following pages in the given way:

  • Add the specialist on the Project Page permission.
  • Restrict the Technical Documentation in the same way as the Project Page, but without the specialist.
  • Restrict the Concept Two in the same way as the Project Page, but without the specialist

Only in this way all other pages are restricted as before and the specialist gets access to the given page. If you now imagine that you have more than two concepts and some additional pages below Technical Documentation and you like to give multiple users different access permission for different pages, you get an idea of how complex it could get. Such cases often will lead to security problems as users simply open up a whole section (Concepts) for external users without restricting parallel structures (Technical Documentation).

If your system is quite new, you can act in advance and create a rule for your users, how they should use the restriction-permission, or you can restrict the user group who can use the restriction permission.

If however there occurs a space with a complex page restriction situation, there is no simple solution. You can try to cut the Gordian Knot and follow one of our recommendations below.

3.) If the Project Page is restricted to the team and a user likes to give a specialist access just to the page “Concept One” and he just adds the permission on the page “Concept One” it looks like the specialist has access, but in fact he will not be able to see the page. This will cause at least some confusion as Confluence will not prevent the possibility to add page restrictions which are logically not possible, but will respect the inherited page restriction.

INFO: How to handle page restrictions

Our recommendation for this is to follow the wiki approach. All content is public, or at least open to everyone with space access. If you need an argument you could use the following one: Since every employee of your company has signed a statement of secrecy there is no need to restrict access to specific information within a project space.

If however you like to or have to implement restrictions on page level, do this only on pages of one level of your overall structure or at the last hierarchy level. In this way you will reduce the complexity of restrictions.

Wiki gardening for space administrators

Now we have some recurring tasks for your space administrator. Some of them are not security related at first sight, but they are if you have a closer look.

Based on the delete permission, any space administrator should review the trash from time to time and purge everything as the task to find a specific page in your trash is kind of impossible if you have hundreds or thousands of pages in it. If the space administrator does not do this the pages are still in your system and if your system will be hacked the information on your deleted pages can be accessed.

Visit the Orphans regularly and be aware of dead links:

  • Orphans are pages without parents and incoming links from other pages. In order to find them, your space administrator should have a look at the root level of your page hierarchy, i.e. the level in which your Home Page is located. If your users delete pages that have child-pages, those child-pages will not be deleted. They will be relocated to the root level of your space.In default configuration you will not see the root level in your space navigation, but you can access them via the navigation menu at the bottom left and the reorder pages menu-item there or on the menu-item “Content Tools” and here within the “Orphan Pages” tab. Here your space administrator should delete those pages from time to time. We recommend to contact the creator or the last editor before you delete it and inform them. If you don’t delete those pages it may happen that all users get access to information that has been restricted before, if the pages were part of a restricted part of your page hierarchy.
  • Undefined pages are so called dead links or links with no target page. They can be created as “Add link to create page” or if you delete pages with incoming links without editing the given source pages of those links. Normally, Confluence will handle such links as if they were created with the “Insert Link” option of the editor. But if you simply pasted the URL or short link on your page, a dead link occurs if the target was deleted. The security risk here is low, but you can follow the argumentation of the shared items in JIRA from above, at least the information that once there were information about a given topic stays in your system.
Conclusion

Even as the Atlassian tools are quite secure, there are some aspects you have to be aware of in order to prevent opening a door for everyone to steal your data. We have introduced you to three basic levels of security:

  • Network and server security
  • Installation and configuration security
  • System-specific security

Each level can be reviewed and worked on by its own. If you have managed to get a secure network and a secure server configuration, you can start to review your installation and overall system configuration including interfaces between different systems. If this is done you can start to review and correct your system-specific configuration. This will take the most time because here you have to adapt your systems in a way that your users will recognize it.

The best way is to be aware of such topics right from the start of the implementation of your Atlassian products. No matter if you use a small 50-User JIRA without any plugins and without any other systems or if you like to implement a 50.000 user data center environment with Confluence, JIRA Software, Bitbucket, Fisheye and Crucible, security should be a topic on your list from day one on.

(c) 2017 mgm technology partners. This posting "System-specific Security for JIRA and Confluence - Security around Atlassian Systems, Part 2" is part of the mgm technology blog. The author of the posting is Benjamin Weinheimer and Björn Kirschner.

We are hiring! mgm technology partners is looking for good software engineers for all our offices. Check out www.mgm-tp.com/karriere.


mgm technology partners GmbH

Logo.jpg20170925 7406 1wgp1bc
Seit 1994 übernimmt mgm technology partners langfristig Anwendungsverantwortung für geschäftskritische Softwaresysteme marktführender Unternehmen und Öffentlicher Institutionen. Wir entwickeln hochskalierbare, integrierbare und sichere Online-Anwendungen für Öffentliche Auftraggeber und Versicherungen sowie für Commerce-Unternehmen. Inzwischen zählen wir uns mit über 400 Mitarbeitern an 12 Standorten weltweit zu den führenden Softwarehäusern für javabasierte Anwendungssysteme. Zusätzlich wird unsere Arbeit durch unsere Tochter mgm consulting partners und deren fast 50 Beratern verstärkt. Unsere Standorte: München (HQ), Bamberg, Berlin, Dresden, Hamburg, Köln, Leipzig, Nürnberg, Grenoble, Prag, Zug, Da Nang und Washington D.C.