Security Issues on WebHooks

[Taryck BENSIALI]

Hi,

I start sudying the opportunities of the webhook on Jira.

While this features is describe has a great change, I realize that there is no information on authentification. I mean a callback is made on an URL but nothing is done to provide credential to ensure the identity of the URL Caller.

After few search I found this issues : JRASERVER-31953 : Not being able to create webhooks with basic authentication

While it's open from 3 years now, no change.

Does anyone has a REAL and SECURE workaround ?

I expect each calback call provide a certificate to authentify the caller.

The only solution I've got is to :

1. creating some proxy code on the tomcat on which runs JIRA
2. Ensure this proxy only accept calls from it self (may be listening to IP 127.0.0.1)
3. Map URL where he listen to remote URL and Add certificate to the call

It's quite ugly, but because Atlassion doesn't provide any suitable solution it required.

Does anyone has done this and could share the result ?

Does anyone has a better solution ?

[Thomas Deiler]

Dear @Taryck BENSIALI,

I have not yet needed webhooks that much, but you are totally right. I would realize it the same way you described - proxy the calls to add security.

So long

Thomas

[Taryck BENSIALI]

Thanks, I work for military companies, where security is really a fundamental matter.

I'm not sure they will accept such a solution because communication between JIRA and proxy could be fake by any code that run on tomcat.

[Taryck BENSIALI]

I wondering if it's possible to build an add-on / Plufg-in for Jira that recieve internal event that are processed by the webhook, and send them on a callback maner (like webhooks do) BUT with authentication :

• Basic : user + pwd (not in URL)
• Certificat X509 on HTTP header

Because after waiting for 3 years for Atlassian to add security to webhook, it's time to accept they will never do anything and do something to secure the webhooks...

[Thomas Deiler]

Dear @Taryck BENSIALI, that's a matter of resources and which requirements are loved by the mass. To be honest, I think this fine mechanism of web hooks is only used by a few installations.

But back to your security problem. I understand your environment and its needs. If a man in the middle attack is possible you can do following:

Write on an isolated system your own service, that communicants with Jira over SSL secured REST API. Then this service can also fully implement another secure call to a web server or even something different like a direct DB access.

You have to care about a polling mechanism. The service has to ask Jira for changes, nothing is triggered automatically. If you can wait from the event to "some" action for a couple of seconds, then this should work for you.

If done with some lines of PHP/Python code, I would say this is done in 1-2 days. In high-level languages (Java/C++), this could take a little bit longer, but not at all a too big deal.

So long

Thomas

[Taryck BENSIALI]

Well, I've developed on SAP connection to REST API. It's quite simple if we solve the "customfield" question. I haven't explored much web hook be I do not get suitable situation, until today.

However polling JIRA from time to time to be informed on change is not a great architecture solution. Using WebHooks is the solution if we could get something secured.

When on such situation you've got to make communicate 2 softwares you can't ask to IT department to add a new one just is juste... unaceptable.

I just expect web hook to works as it should be. I do not know enought of JIRA API to know if we can create an add-on that will intercept the change events and make a URL callback but with authentification (Basic and then X509 certicates)...

If you know which JIRA API could be used for that it will be a great information. :-)

[Thomas Deiler]

Dear @Taryck BENSIALI,

you have to do first a search. The posted JQL should look like this:

project = XYZ AND status = <status, where you triggered the webhook> AND custom_field_ABC = "new"

The custom field is a flag for marking issues you already have processed. Set by the workflow to "new".

Then you just have to extract the issue information of your choice and send one (own) web hook to somewhere else. After the send you modify the issue, setting the custom field to something different or NULL.

So long

Thomas

[Taryck BENSIALI]

I understand, but it's quite unacceptable to modify project/template by creating a new field in order to get a delta list.

If we need to think on such solution I rather go to the Database it self and search for change timestamp and make my own delta list.

I think proxy still the best option If JIRA Java API doesn't have any thing on webhook.

[Taryck BENSIALI]

I think there is no JAVA API :

JIRA JAVA Doc

JAVA API to create webhooks

webhook backdoor

JiraWebHookListenerActionValidator

[Anthony France]

>t, I think this fine mechanism of web hooks is only used by a few installations.

That's because we CAN'T use them with anything, almost every provider I know of that can consume webhooks requires some sort of authentication... 

[Gabriel Moysés Delfino]

Hi @Taryck BENSIALI

I'm facing this same problem right now. The suggestion (https://jira.atlassian.com/browse/JRASERVER-31953?_ga=2.151913724.456297363.1536177229-2028571475.1533578870) is still not being considered. Therefore, I ask you, could you manage to find a better solution or are you still using the proxy running on TomCat? Does it work satisfactorily?

Respectfully,

Gabriel Delfino

[Taryck BENSIALI]

Hi,

We do not implement this workaround (unaceptable for security reason).

But I recieve the info (I do not remember where) that basic authentification is now supported.

I hope it's helps.