Support for Webhook Secret
Opened this issue · 3 comments
GitLab support "Secret token" when sending webhooks:
Used to validate received payloads. Sent with the request in the X-Gitlab-Token HTTP header.
Adding this support into ucascade would make it a lot more safe
To my knowledge there is no validation payload, since the secret is sent in clear text.
Gitlab documentation: https://docs.gitlab.com/ee/user/project/integrations/webhooks.html
We would need this to make it really secure:
https://gitlab.com/gitlab-org/gitlab/-/issues/19367
(the secret would be kept secret on both side and used at ucascade side to make sure it was sent by the server, by verifying the hash)
Because right now the "a lot more safe" part is not really granted.
We have something similar in an other tool (receiving web-hooks from SonarQube / SonarCloud)
There is an optional config for the secret:
https://github.com/unblu/u-sonar-status/blob/8ac7565caed79618bfd5cb6b40d65efc345246ec/src/main/java/com/unblu/usonarstatus/service/EventController.java#L44C1-L45
And then when we get an event we make sure that is a secret is configured we should have a hmacValue
(that we get from the header with @Header("x-sonar-webhook-hmac-sha256") String hmacValue
) and if no secret-config is provided then we also do not expect the header value:
https://github.com/unblu/u-sonar-status/blob/8ac7565caed79618bfd5cb6b40d65efc345246ec/src/main/java/com/unblu/usonarstatus/service/EventController.java#L73-L97
In the case of GitLab this would be even simpler since we would just have to check for the presence of the x-gitlab-token
header and a validation of its content (that should match the configured value). We would not have to calculate an HMAC signature, but just do a String equals on the header value.
We accept a PR for this feature request