unblu/ucascade

Support for Webhook Secret

Opened this issue · 3 comments

rtuk commented

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.
image

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