Restrict unauthenticated access for some Jira endpoints
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Please note the following information is provided as-is. Atlassian Support cannot provide further assistance with the proxy configuration described below.
Summary
The vulnerability was found in that the project categories, status categories, issue link types, priorities, resolutions, and others listed below are visible to anonymous users via REST API even if anonymous access is disabled. It is logged in the following bug ticket:
Environment
8.1x.x
8.2x.x
9.x
Diagnosis
Affected versions of Atlassian Jira Server and Data Center allow an Un-Authenticated attacker to view Project categories, status categories, issue link types, priorities, and resolutions via an Information Disclosure vulnerability on the following endpoints:
1
2
3
4
5
6
7
8
9
10
11
12
<BaseURL>/rest/api/2/issueLinkType
<BaseURL>/rest/api/2/priority
<BaseURL>/rest/api/2/projectCategory
<BaseURL>/rest/api/2/resolution
<BaseURL>/rest/api/2/status
<BaseURL>/rest/api/2/statuscategory
<BaseURL>/rest/api/2/projectvalidate/key?key=
<BaseURL>/rest/api/2/jql/autocompletedata/
<BaseURL>/rest/api/latest/avatar/project/system
<BaseURL>/rest/api/2/field
<BaseURL>/rest/api/2/screens
<BaseURL>/rest/api/1.0/issues/2346583/ActionsAndOperationsNote: the following endpoints appear to no longer be vulnerable in v8.15.0:
1
2
3
<BaseURL>/rest/api/2/status
<BaseURL>/rest/api/2/projectvalidate/key?key=
<BaseURL>/rest/api/1.0/issues/10000/ActionsAndOperationsFor some endpoints, there aren't dark features available:
1
2
3
4
<BaseURL>/rest/menu/latest/appswitcher
<BaseURL>/rest/menu/latest/admin
<BaseURL>/rest/menu/latest/home
<BaseURL>/rest/menu/latest/profileSolution
Below are adjusted to include all the identified endpoints to block these endpoints either for unauthenticated users at the reverse proxy or within Tomcat, such as by adding the following settings to the urlrewrite.xml file:
$JIRA_INSTALL/atlassian-jira/WEB-INF/urlrewrite.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
<!-- block issuelinktype -->
<rule>
<from>(?s)^/rest/api/.*/issueLinkType</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block priority -->
<rule>
<from>(?s)^/rest/api/.*/priority</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block projectcategory -->
<rule>
<from>(?s)^/rest/api/.*/projectCategory</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block resolution -->
<rule>
<from>(?s)^/rest/api/.*/resolution</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block statuscategory -->
<rule>
<from>(?s)^/rest/api/.*/statuscategory</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block jql/autocompletedata -->
<rule>
<from>(?s)^/rest/api/.*/jql/autocompletedata</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block field -->
<rule>
<from>(?s)^/rest/api/.*/field</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block screens -->
<rule>
<from>(?s)^/rest/api/.*/screens</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block avatar/project/system -->
<rule>
<from>(?s)^/rest/api/.*/avatar/project/system</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block serverInfo -->
<rule>
<from>(?s)^/rest/api/.*/serverInfo</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block appswitcher -->
<rule>
<from>(?s)^/rest/menu/.*/appswitcher</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block admin -->
<rule>
<from>(?s)^/rest/menu/.*/admin</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block home -->
<rule>
<from>(?s)^/rest/menu/.*/home</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
<!-- block profile -->
<rule>
<from>(?s)^/rest/menu/.*/profile</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>ℹ️Note: this rule structure above works well for API endpoints, but not for UI pages. For user pages, a better approach is to forward them to the home page.
For example:
1
2
3
4
5
6
<!-- Forwarding BrowseProjects.jspa -->
<rule>
<from>(?s)^/secure/project/BrowseProjects.jspa$</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<to>/secure/MyJiraHome.jspa</to>
</rule> If for whatever reason you have scripted basic authentication calls to these endpoints e.g. (python/curl requests), they will all be blocked, with the user authenticated, or not. For alternative authentication methods please refer to the Security overview.
Be careful blocking the endpoint: <BaseURL>/rest/api/2/jql/autocompletedata/. It can compromise the suggestions in JQL advanced search.
Regarding the endpoint - "<BaseURL>/rest/api/latest/serverInfo": There is a Suggestion to hide this and there is also a related bug.
Ability to disable/hide the REST endpoint for serverInfo (JRASERVER-62282)
It is possible to hide this information from JIRA pages by modifying the footer: $JIRA_INSTALL/atlassian-jira/WEB-INF/classes/templates/plugins/footer/footer.vm
On Jira 8.x to restrict anonymous access to the endpoint you may disable it by using the feature flag aka provide <feature.flag>.disabled:
Endpoint | What changes | Feature flag |
|---|---|---|
/rest/api/2/issueLinkType | Anonymous access was disabled completely | com.atlassian.jira.security.endpoint.anonymous.access.issueLinkType |
/rest/api/2/priority | Anonymous access is blocked only when there are no projects available for anonymous users | com.atlassian.jira.security.endpoint.anonymous.access.priority |
/rest/api/2/projectCategory | Anonymous access was disabled completely | com.atlassian.jira.security.endpoint.anonymous.access.projectCategory |
/rest/api/2/resolution | Anonymous access is blocked only when there are no projects available for anonymous users | com.atlassian.jira.security.endpoint.anonymous.access.resolution |
/rest/api/2/jql/autocompletedata/ | Anonymous access is blocked only when there are no projects available for anonymous users | com.atlassian.jira.security.endpoint.non.browse.projects.access.autocompletedata |
/rest/api/latest/avatar/project/system | Anonymous access was disabled completely | com.atlassian.jira.security.endpoint.non.admin.access.avatar.system |
/rest/api/2/field | Anonymous access is blocked only when there are no projects available for anonymous users | com.atlassian.jira.security.endpoint.non.browse.projects.access.fields |
/rest/api/2/screens | Only admins have access to this endpoint | com.atlassian.jira.security.endpoint.non.admin.access.screens |
The only workaround currently known to the endpoints there isn't a dark flag available is:
API gateway/proxy setup or whitelist IPs that are trusted. Please refer to How to block access to a specific URL at Tomcat.
ℹ️ Some of the 3rd party integrations may use this endpoint to determine if it's a Server or Cloud instance and on what version is it running.
To Jira 9.x there are some endpoints already blocked by default as you can see in Jira Software 9.0.x release notes:
We’ve made security improvements to our APIs. Starting from Jira 9.0, anonymous users will have no access to the following API endpoints:
<BaseURL>/rest/api/2/field<BaseURL>/rest/api/2/issueLinkType<BaseURL>/rest/api/2/jql/autocompletedata/<BaseURL>/rest/api/2/priority<BaseURL>/rest/api/2/projectCategory<BaseURL>/rest/api/2/resolution<BaseURL>/rest/api/2/screens<BaseURL>/rest/api/latest/avatar/project/system
It's still possible to enable anonymous access for listed endpoints on Jira 9.0 and some later versions. However, the access will be disabled permanently in the upcoming LTS release.
Consider that some project categories, status categories, issue link types, priorities, and resolutions may be accessible to anonymous users even if anonymous access is disabled. To restrict anonymous access to endpoints on Jira 9.0, you need to enable a dark feature in Jira by providing <feature.flag>.enabled. Check the upgrade notes for details.
For more information about the <BaseURL> and the $JIRA_INSTALL directory please refer respectively to Configuring the base URL and Jira application installation directory.
For more information on customizing URL rewrite, check UrlRewriteFilter Manual page.
Was this helpful?