Stream: subscriptions
Topic: Securing webhooks
Grahame Grieve (Sep 04 2018 at 04:44):
I'm listening to a presentation on securing web hooks. The presenter is engineering manager for a web api intermediary. He's arguing that the only truly secure way to secure a web hook is an HMAC signature using PKI that includes some / all of the header + body, particularly including the http timestamp
Grahame Grieve (Sep 04 2018 at 04:44):
we haven't talked about this before. thoughts?
Michael Lawley (Sep 04 2018 at 04:52):
One approach is to avoid sending any sensitive info in the hook - it's just a notification to the client & then the client uses normal auth to get the data. This, of course, means potentially more traffic / latency & also assumes that the notification itself doesn't leak information.
Grahame Grieve (Sep 04 2018 at 06:17):
Yep we’ve done that - just call a client specified endpoint with client specified headers. No information from the server in the call
Nick Hatt (Sep 04 2018 at 13:18):
You still want to have some kind of signature on the webhook, so that the receiver can verify the webhook came from a trusted party. A potential attack would be denial of, bring down an FHIR server by pretending to send subscription notifications from it.
Isaac Vetter (Sep 04 2018 at 13:36):
Grahame - I've been imagining a signed JWT, a la CDS Hooks for the case where the FHIR server must authenticate to the subscriber. I'd argue that there's no "truly secure way" to do anything, rather it's about risk tolerance.
Grahame Grieve (Sep 04 2018 at 20:42):
does a signed jwt bring anything over a simpler hash?
Last updated: Apr 12 2022 at 19:14 UTC
