Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-38548

Remove url parameter support for os_username, os_password

XMLWordPrintable

    • 7.13
    • 9
    • Severity 1 - Critical
    • 14
    • Hide
      Atlassian Update – 21st September 2020

      Hi everyone,

      We would like to inform you that from Jira 8.14 and later we’ll be blocking the default possibility to log into Jira by passing credentials via URL parameters (see https://jira.atlassian.com/browse/JRASERVER-38548).

      This method of authentication has been deprecated since the release of Jira 8.0 on 11th Feb 2019 (see https://jira.atlassian.com/browse/JRASERVER-67979).

      Since the credentials might end up as a plain text entry in different log files (such as that of load balancers or proxies), this method poses a security risk. To mitigate it, we want to block its default availability, and make it an option only in special cases. We’ll also sanitize the access logs of the Tomcat web server bundled with Jira.
      However, for the internal and legacy integrations to keep working, we still want to provide a way to use this method. You’ll have to set a special system property. That way your legacy and/or internal integrations will still work. To keep your logs under control, it’s also a good idea to review your logs for possible credential entries.
      If you have any feedback regarding this change, feel free to leave us a comment.

      Yours,
      The Jira Server Team

      Show
      Atlassian Update – 21st September 2020 Hi everyone, We would like to inform you that from Jira 8.14 and later we’ll be blocking the default possibility to log into Jira by passing credentials via URL parameters (see  https://jira.atlassian.com/browse/JRASERVER-38548 ). This method of authentication has been deprecated since the release of Jira 8.0 on 11th Feb 2019 (see  https://jira.atlassian.com/browse/JRASERVER-67979 ). Since the credentials might end up as a plain text entry in different log files (such as that of load balancers or proxies), this method poses a security risk. To mitigate it, we want to block its default availability, and make it an option only in special cases. We’ll also sanitize the access logs of the Tomcat web server bundled with Jira. However, for the internal and legacy integrations to keep working, we still want to provide a way to use this method. You’ll have to set a special system property. That way your legacy and/or internal integrations will still work. To keep your logs under control, it’s also a good idea to review your logs for possible credential entries. If you have any feedback regarding this change, feel free to leave us a comment. Yours, The Jira Server Team

      Putting credentials in request parameters is likely to lead to those credentials being logged in access logs.

       

      Workaround

      The following workaround is available in Jira 8.0.0 and higher versions.

      If you wish to prevent users from authenticating using url parameters, specifying their username & password in url parameters, then
      1. Stop Jira
      2. Open <Jira-installation-directory>/WEB-INF/web.xml
      3. Search for `<param-name>allowUrlParameterValue</param-name>`
      4. Modify `<param-value>true</param-value>` to <param-value>false</param-value>
      5. Start Jira.

      Note prior to making this change we suggest checking your Jira log files for log events like the following

      User "example-user" authenticated using os_password as a query parameter, this means of authentication has been deprecated.

            [JRASERVER-38548] Remove url parameter support for os_username, os_password

            Security Metrics Bot added a comment -

            Since it has the 'security' label, this ticket has been imported into Vulnerability Funnel as: https://asecurityteam.atlassian.net/browse/VULN-197103

            The issue will be triaged by the Product Security team and if it is determined to be a security vulnerability, it will need to be completed prior to the assigned security SLO due date.

            For more information on how Atlassian handles security vulnerabilities, see the Security Vulnerabilities - User Guide

            To avoid duplicate issues, please do not remove the 'security-imported' label from this issue.

            Security Metrics Bot added a comment - Since it has the 'security' label, this ticket has been imported into Vulnerability Funnel as: https://asecurityteam.atlassian.net/browse/VULN-197103 The issue will be triaged by the Product Security team and if it is determined to be a security vulnerability, it will need to be completed prior to the assigned security SLO due date. For more information on how Atlassian handles security vulnerabilities, see the Security Vulnerabilities - User Guide To avoid duplicate issues, please do not remove the 'security-imported' label from this issue.

            Christopher Fani added a comment -

            I am also failing a security audit and was curious if there has been any movement on this issue.  

            Christopher Fani added a comment - I am also failing a security audit and was curious if there has been any movement on this issue.  

            Ignat (Inactive) added a comment -

            Hi tdmcgough1124377020,

            Yes, this is something we'd like to address in the long run.

            Unfortunately removing this may break integrations, those who use parameters to get authorised access e.g. third-party gadgets, etc, - so it is not just something we can do overnight.

            Just wanted to re-assure we plan to address the future - however, given the number of moving parts, it will take us few releases to completely get rid of passing the parameters via URL.

            Cheers,
            Ignat
            JIRA Bugmaster.

            Ignat (Inactive) added a comment - Hi tdmcgough1124377020 , Yes, this is something we'd like to address in the long run. Unfortunately removing this may break integrations, those who use parameters to get authorised access e.g. third-party gadgets, etc, - so it is not just something we can do overnight. Just wanted to re-assure we plan to address the future - however, given the number of moving parts, it will take us few releases to completely get rid of passing the parameters via URL. Cheers, Ignat JIRA Bugmaster.

            Tim McGough added a comment -

            We continue to fail a security audit because of this issue.  Has there been any work done on this issue in the past three years?

            Tim McGough added a comment - We continue to fail a security audit because of this issue.  Has there been any work done on this issue in the past three years?

            Donald McDowell added a comment -

            Has anyone found a workaround for this fix ?

            Donald McDowell added a comment - Has anyone found a workaround for this fix ?

            MattS added a comment -

            I agree, but I think that more documentation examples of how to access JIRA remotely and simply from a variety of tools is needed before you remove them. People keep using them because they can't get the other approaches to work for them. Honest!

            MattS added a comment - I agree, but I think that more documentation examples of how to access JIRA remotely and simply from a variety of tools is needed before you remove them. People keep using them because they can't get the other approaches to work for them. Honest!

              pcegla Pawel Cegla
              dblack David Black
              Affected customers:
              7 This affects my team
              Watchers:
              25 Start watching this issue

                Created:
                Updated:
                Resolved: