tracker.org
This commit is contained in:
parent
facca1dd34
commit
79c4b93af4
1 changed files with 16 additions and 0 deletions
16
tracker.org
16
tracker.org
|
@ -622,3 +622,19 @@ The call must be authenticated by the API.
|
||||||
The call should also optionally contain access/refresh tokens to the
|
The call should also optionally contain access/refresh tokens to the
|
||||||
destination so the integration team could access IROH as the event's
|
destination so the integration team could access IROH as the event's
|
||||||
emitter user.
|
emitter user.
|
||||||
|
|
||||||
|
The issue is that, nothing is explicitly done to prevent any user to get an
|
||||||
|
access/id token generated from the same client we use to forge the
|
||||||
|
authentication headers.
|
||||||
|
So it means, that a SecureX user from any org that could get access to its
|
||||||
|
own access token/id token (which is entirely possible, and easy to get for
|
||||||
|
DI as their client is public).
|
||||||
|
So any user could call the API endpoint to fake real webhook events, and
|
||||||
|
potentially using cross-tenancy/cross-user false events.
|
||||||
|
|
||||||
|
So to mitigate this issue, we suggest to:
|
||||||
|
|
||||||
|
1. Always use the owner of the webhook & the client of the team to build
|
||||||
|
id_tokens, (if possible not access_token).
|
||||||
|
The forged JWT should have a specific audience (this is already the case
|
||||||
|
for DI at least)
|
||||||
|
|
Loading…
Reference in a new issue