Use HMAC for signing webhooks

[captn3m0]

• Gitea version (or commit ref): 1.4.1
• Git version: NA
• Operating system: NA
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant
• Log gist:

Description

Several tools rely on standard GitHub webhooks, which include a X-Hub-Signature header to validate the webhook. Gitea sends the secret in the payload JSON itself, which doesn't work for all services.

The standard github event signature is a simple HMAC-SHA1 of the request payload with the secret as the key. [Docs]

Screenshots

[bradrydzewski]

This would be a nice feature. For reference, here are what some of the other providers are doing:

• GitLab sends the secret in X-Gitlab-Token: {secret}
• GitHub sends the webhook hmac signature in X-Hub-Signature: sha1={hash}
• Bitbucket server sends the webhook hmac in X-Hub-Signature: sha256={hash}
• Gogs sends the webhook hmac signature in X-Hub-Signature: {hash}

[simbo1905]

Is there a security label that can be added to this ticket? The current method of sending the secret in the payload in plain text is considerably less secure than GitHub, GitLab, BitBucket and Gogs that are hashing the payload.

[titpetric]

Is somebody working on this? I'd like to implement it against the GitHub specs (HMAC-SHA1), if somebody volunteers to field the PR. Would love to see this in a future version to integrate against Abstruse CI.

[titpetric]

I tracked down the relevant commit adding this in gogs: 3609efe2. The signature header there is prefixed with X-Gogs, suggesting we should have X-Gitea here.

[lunny]

@titpetric Nobody are working on this. Please send a PR to fix this.

[titpetric]

Migrated to drone, which supports the current Gitea payloads, was for the best.

[simbo1905]

We are using adnanh/webhook and wrote matching rules that work for either Gitea or Github. The point here is not that you cannot match on a secret in the body the point is that it is a less secure approach.

[titpetric]

@simbo1905 I agree 100%, but effectively this either means choose a limited set of CI’s that support Gitea, or switch out Gitea for a more secure alternative. I didn’t necessarily want to PR against abstuse CI and at the same time, any PR against gitea might take weeks or months in the pipeline before being merged (if). The reality is that we needed to choose what works without having to build it out on either side.

[lunny]

@titpetric Not all PRs took a long time. For those PRs which needs more review and tests, we have to spend more time on it to reduce bugs or regressions . A PR to fix this issue is welcome.

[urbanswelt]

I am here to test the PR =)

[techknowlogick]

@urbanswelt please see linked PR

[zobo]

Ah.. Missed it by a day :) #6430

Btw: I also added Header("X-Hub-Signature", "sha256=" + t.Signature). to be compatible with more clients.

[urbanswelt]

@techknowlogick

Back from Testing:

Fresh compiled from Master branch today and initial setup done.

Signature would be generated when we fill up the "Secret" field.

#6430 will handle the json body if i see that correct.
Perfect work so far ! ;-)

[zobo]

Correct. Should I create a different issue to track that part?