search

gustavkarlsson / rocketchat-jira-trigger

Outgoing webhook integration for Rocket.Chat that summarizes any JIRA issues mentioned
MIT License
42 stars 19 forks source link

Verify requesting user view permission #41

Open eloo opened 7 years ago

eloo commented 7 years ago

Relating to security and privacy it would be great if the requesting user could be verified that he is permitted to view the request issue. If the user has access the issue should be posted otherwise nothing should happen.

Do you plan to implement such a security feature?

gustavkarlsson commented 7 years ago

It sounds like a great idea. I'm not sure how easy it is, but I'll have a look at it.

eloo commented 7 years ago

okay. thanks

gustavkarlsson commented 7 years ago

The following REST call seems to accomplish this so I think there is a way forward: https://docs.atlassian.com/jira/REST/cloud/#api/2/user-findUsersWithBrowsePermission

@Eloo Just to clarify something: Doing this only really works if the user names in rocket-chat matches those in JIRA. I hope this is the case in your organization.

eloo commented 7 years ago

@gustavkarlsson nice research done from your site. this endpoint is exactly what we need.

yeah normally the username is the email address of a user. this, i guess, applies to most companies.

maybe this feature should be configurable (enable/disable)

gustavkarlsson commented 7 years ago

@Eloo It should definitely be configurable (and disabled by default).

However, I've been thinking more about security issues lately, and I'm weary of the false sense of security this gives users...

If the JIRA setup contains issues that are hidden from some users, others that have the permission to view it might accidentally "expose" it merely by mentioning the issue key.

This is already an issue if the "login user" if given access to limited visibility issues, but at least that can be managed by a security-aware admin.

Maybe a better solution would be to only show issues that are visible to all users?

eloo commented 7 years ago

@gustavkarlsson yeah we discussed this too but the requester should be aware of who is reading a message. because other may non-public content could also be shared by simply chatting around. the vulnerability we want to fix with the requester verification is a simple bruteforce attack on an issue-key. and this could be done by verifing who is requesting an issuekey

gustavkarlsson commented 7 years ago

You've got a point there. I'll have to document this behavior so that people understand the implications, but I think this is still probably the best solution to the problem.

eloo commented 7 years ago

yes this must be documented. further in future a check for all readers in a room could be useful to. but in first instance requester verification is quit good!