• 16
    • 35
    • Hide
      Atlassian Update – 8th February 2018

      Hi all,

      Thanks for your interest in this issue.

      While this suggestion has gathered significant interest, we're unable to implement all of the excellent suggestions you make. We appreciate the benefits of such requests, but don't plan to work on this for the foreseeable future.

      This suggestion will be reviewed in about 12 month's time, at which point we’ll consider whether we need to alter its status.

      Cheers,
      Jira Server Product Management

      Show
      Atlassian Update – 8th February 2018 Hi all, Thanks for your interest in this issue. While this suggestion has gathered significant interest, we're unable to implement all of the excellent suggestions you make. We appreciate the benefits of such requests, but don't plan to work on this for the foreseeable future. This suggestion will be reviewed in about 12 month's time, at which point we’ll consider whether we need to alter its status. Cheers, Jira Server Product Management
    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for JIRA Server. Using JIRA Cloud? See the corresponding suggestion.

      Using the procedures to use basic auth described on

      https://extranet.atlassian.com/display/SUPPORT/Webhooks+readiness+for+JIRA+5.2

      we are getting a "Invalid URL" message.

      workaround
      For Atlassian applications, the REST plugin : https://developer.atlassian.com/display/DOCS/REST+and+os_authType allows you to apend the authentication type to the URL. This can be adapted as a workaround. When I add the os_oauthtype to the URL, it works:

      http://localhost:10520/bamboo52/rest/api/latest/server/pause?os_authtype=basic&os_username=admin&os_password=admin
      

      Note: While this workaround works, it's not great because applications frequently log URLs (for example, Apache can be configured that way) and this means that the password will be leaked, which is not desirable. The risk is highly reduced for users who are not logging access to their system and who are running behind https. We will advice that users take necessary steps to further secure access if they are using this method of authentication.

            [JRASERVER-31953] Not being able to create webhooks with basic authentication.

            daniel.wendler added a comment - - edited

            I know that there is a general risk of leaking data through query strings, but the risk is considerable low with Jira Webhooks.

            There are several ways that add security and lower the risk of fraud:

            1. Use the Jira REST API to check back if the data you been notified about is real. This is the most secure mechanism of all.
            2. Check for the calling hostname as written in my above comment
            3. Consider Jira data as not trustworthy at all.
            4. Rotate a long hash in the webhook URL and disable access logs.

            Basic Auth adds only little security and is less secure used solely. You should combine two or more of the above and be pretty safe.

            Admittedly, it takes more time to implement.

            @Victor I'm not saying "There should be no auth", I'm saying that "Basic Auth" is only "basic".

            daniel.wendler added a comment - - edited I know that there is a general risk of leaking data through query strings, but the risk is considerable low with Jira Webhooks. There are several ways that add security and lower the risk of fraud: Use the Jira REST API to check back if the data you been notified about is real. This is the most secure mechanism of all. Check for the calling hostname as written in my above comment Consider Jira data as not trustworthy at all. Rotate a long hash in the webhook URL and disable access logs. Basic Auth adds only little security and is less secure used solely. You should combine two or more of the above and be pretty safe. Admittedly, it takes more time to implement. @Victor I'm not saying "There should be no auth", I'm saying that "Basic Auth" is only "basic".

            So you are saying if I wanted to send Jira Event Data via Web Hooks to another application there should be no auth required. That makes ZERO sense.  

            Victor Chirinian added a comment - So you are saying if I wanted to send Jira Event Data via Web Hooks to another application there should be no auth required. That makes ZERO sense.  

            Joeri Jansen added a comment - @Daniel: are you serious?  https://owasp.org/www-community/vulnerabilities/Information_exposure_through_query_strings_in_url

            Dudes, there is not really a need for basic auth here.

            For your listener, use an Address like https://..../external/listener/1231290u57io13hjr13ht13t924hgio24fjeklsjfhsg8h4gp4gw4/jira/..../

            Then in your webserver, disable access.log for https://..../external/listener/

            If someone is able to steal your server logs, a basic auth does not protect you either way.

            daniel.wendler added a comment - Dudes, there is not really a need for basic auth here. For your listener, use an Address like https://..../external/listener/1231290u57io13hjr13ht13t924hgio24fjeklsjfhsg8h4gp4gw4/jira/..../ Then in your webserver, disable access.log for https://..../external/listener/ If someone is able to steal your server logs, a basic auth does not protect you either way.

            Totally agree, why Atlassian, why do you not provide something so obvious?

            Richard Jones added a comment - Totally agree, why Atlassian, why do you not provide something so obvious?

            omg! I wasted two hours trying to make this work and basic authentication is not even supported. This is absurd.

            Diego Cantor added a comment - omg! I wasted two hours trying to make this work and basic authentication is not even supported. This is absurd.

            David Sumlin added a comment - - edited

            Finding this issue still sitting out here 7+ years later is so disheartening. Customers begging for basic common sense functionality from Atlassian seems to be the status quo.  I guess the concept of data privacy or GDPR isn't a concern.

            David Sumlin added a comment - - edited Finding this issue still sitting out here 7+ years later is so disheartening. Customers begging for basic common sense functionality from Atlassian seems to be the status quo.  I guess the concept of data privacy or GDPR isn't a concern.

            I totally agree with the comments above: we cannot expose an API without authentication. We live in the year 2020! It is just an http header to set, how hard can it be to implement?

            joeri.jansen@technolution.eu added a comment - I totally agree with the comments above: we cannot expose an API without authentication. We live in the year 2020! It is just an http header to set, how hard can it be to implement?

            Hi team, this is really annoying to see a functionality is not completely implemented. Why would someone expose their API without the authentication?! The issue type here shouldn't be a "suggestion" but to "fix the basic functionality". Please implement this as soon as possible, otherwise remove the webhook option itself . Its good for nothing if there's no way to mention the authentication details.

            Prasanna Shasthri added a comment - Hi team, this is really annoying to see a functionality is not completely implemented. Why would someone expose their API without the authentication?! The issue type here shouldn't be a "suggestion" but to "fix the basic functionality". Please implement this as soon as possible, otherwise remove the webhook option itself . Its good for nothing if there's no way to mention the authentication details.

            Kaitsu added a comment -

            Hi Jira Server Product Management team! It's been more than 2 years since you commented this issue last time. Could you please give us an update, even if it's stating that you're not going to implement this security feature?

             

            Currently, as an Integrator, you are faced with a decision to either add some form of an authentication token directly to the url (not optimal for reasons already stated several times in the comments above), or use pull instead of this event-driven webhook push mechanism (not optimal either as you lose real-time and might also miss updates). 

            Kaitsu added a comment - Hi Jira Server Product Management team! It's been more than 2 years since you commented this issue last time. Could you please give us an update, even if it's stating that you're not going to implement this security feature?   Currently, as an Integrator, you are faced with a decision to either add some form of an authentication token directly to the url (not optimal for reasons already stated several times in the comments above), or use pull instead of this event-driven webhook push mechanism (not optimal either as you lose real-time and might also miss updates). 

              Unassigned Unassigned
              llima LucasA
              Votes:
              283 Vote for this issue
              Watchers:
              174 Start watching this issue

                Created:
                Updated: