-
Bug
-
Resolution: Fixed
-
Low (View bug fix roadmap)
-
8.5.4, 8.5.9, 8.16.0, 8.13.11
-
8.05
-
10
-
Severity 3 - Minor
-
1
-
Issue Summary
Endpoint "rest/config/1.0/directory" can be accessed anonymously. This page is an XML output that exposes the gadgets installed on the Jira instance.
While there are not be any identifying information, user data, or anything else available to anonymous users if they hit this URL, a potential bad actor could better understand which add-ons customers have installed into theirJira instance and use that information to their advantage to attack them. This could be through malicious attacks that exploit those add-ons specifically, taking advantage of possible security vulnerabilities of those instances, or phishing-like attacks where the bad actor may impersonate vendors to get information from us.
Steps to Reproduce
Access <JIRA BASE URL>/rest/config/1.0/directory anonymously
Expected Results
The user gets redirected to log in
Actual Results
The page is shown:
Notes
This happens even if the public access is blocked using a flag in the dark features
This page is used by the Jira gadget plugin so we don't recommend blocking it as it might cause some functionalities to fail in Jira, and this was not tested.
Workaround
Block the unauthenticated access to this particular URL */rest/config/1.0/directory at the network level. For example, block the URL from being accessed from the proxy side. Another option is doing it from Apache Tomcat: How to block access to a specific URL at Tomcat
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JRASERVER-72613] Anonymous users can view list of installed gadgets in Jira
I added <security-constraint> tag in web.xml, a solution given in one the links in this ticket. It worked.
Adding rule to Confluence's urlrewrite.xml did not work for Confluence version 7.12.0.
Has anyone figured out if any of the proposed workarounds break Jira or Confluence (https://jira.atlassian.com/browse/CONFSERVER-68756) in anyway?
Confluence uses Tomcat, too. So I don't see why it wouldn't. The urlrewrite.xml file is located at <Confluence-Install-Directory>/confluence/WEB-INF/urlrewrite.xml on a standard Confluence Server or Data Center installation.
Confluence seems to have the same issue btw, but i can't find a bug for that - any idea if the same workaround applies to Confluence too?
Rather than using our proxy or tomcat config to restrict access to this endpoint, I added the following block to <Jira-Install-Directory>/atlassian-jira/WEB-INF/urlrewrite.xml . This allows authenticated users (anyone who's logged in an has an active session cookie) to access the endpoint, but anonymous users are served a 403 unauthorized. The snippet goes between the <urlrewrite> and </urlrewrite> tags.
<rule>
<from>^/rest/config/1.0/directory</from>
<condition type="session-attribute" name="seraph_defaultauthenticator_user" operator="notequal">.+</condition>
<set type="status">403</set>
<to>null</to>
</rule>
This is just a user's attempt at a simple workaround. We haven't noticed any negative effects yet, but I don't know enough about how Jira uses this endpoint to say that this is a good solution. Maybe something to test for yourself if you're looking for a quick fix. You've got to restart Jira after making the change in order for it to take effect.
Well, that's unexpected. And not very welcome. Now people know which plugins we have installed, a precursor to attacking our Jira
Maybe Confluence doesn't use the "seraph_defaultauthenticator_user" attribute like Jira does. Probably best to use the web.xml workaround that Abdul used that's linked in the ticket's description: https://confluence.atlassian.com/kb/how-to-block-access-to-a-specific-url-at-tomcat-966668691.html