Headers sent by webhooks not sufficient to identify sender as Habitica

[Pyromonk]

General Info

• UUID: 74ca0c4c-683d-4012-965a-ba3bc6bb1b13
• Browser and OS: not applicable

Description

I realise that webhook functionality is still in Beta, but I think it is important to mention that the current headers being sent by Habitica to webhooks do not allow to uniquely identify the sender.
It would also be nice if the type of request and format of the data being sent was documented.

[benkelaar]

@Pyromonk Interesting! I'm not on the Habitica team, but perhaps you could expand a bit? Which headers are currently being sent and how are they insufficient to uniquely identify Habitica?

Do you have a link to documentation that properly describes which headers should be there that would sufficiently identify Habitica? Perhaps there's a web standard that can be followed?

It might also help if you describe what it is you actually want to do with the webhook and why them uniquely identifying Habitica is necessary for that usecase.

[citrusella]

I'm not the person who posted the issue here, but I know there was some discussion in Aspiring Comrades a couple days before this issue was created where someone was trying to figure out if the webhook included anything that could be used to be sure the data came from Habitica (versus, for instance, someone maliciously hitting the URL your webhook sends to (i.e. potentially with data that looks like what Habitica sends, which could in theory trigger whatever your webhook is set up for)).

[Pyromonk]

@benkelaar, some of the headers sent that I currently use for identifying Habitica (I could take a look at what the other ones were again, but I don't think they are very relevant): HTTP-USER-AGENT, CONTENT-TYPE and REQUEST-METHOD. HTTP-USER-AGENT is the main one, however, like all other HTTP headers, it can be forged. I also do a check for X-REQUESTED-WITH to "defend" against Ajax requests (Habitica doesn't send an X-REQUESTED-WITH header).

The only way to uniquely identify Habitica would be if Habitica were to send something that only their server knows (for example, the API key; however, the API key is problematic, in that the webhook is not necessarily only used by the person who set up the webhook). That is the only solution I am aware of and what most web services do.

I'm in the process of switching over to receiving a unique parameter as part of the webhook URL, as it seems to be the only solution available at the moment. That is problematic as well, because said parameter has to be shared with whoever is going to use the webhook.

I am working on a tool to trace party activity. Data is stored within my database. Theoretically, someone with knowledge of the URL and the JSON format Habitica uses could send data to my server, pretending to be Habitica, and there would be no way of knowing.

@citrusella, thank you. I have raised this issue because it was mentioned in "Aspiring Comrades". I had taken a look at what data Habitica sends, and it's not enough to uniquely identify the request.

[grelca]

most services solve this by including a signature header in the webhook. basic process for that is to take the body of the webhook and encrypt it with a secret key that both server and client know. the secret key should also be different for every client. that encrypted value is then passed as a signature header and the client can decrypt it using the secret key and verify the decrypted version matches the webhook body.