Stream: implementers
Topic: Subscription REST Hook payload
Da Huang (Nov 05 2018 at 22:07):
Hi all,
According to the spec (https://www.hl7.org/fhir/subscription.html#2.46.6.1), a FHIR server may send the complete resource content as the HTTP POST body to the REST hook endpoint directly when the “payload” field of the subscription is set.
We are concerned that sending full resource content to an endpoint URL may introduce unwanted risk to the ePHI. In our case, we check authentication and authorization when interacting with subscription resources, but we cannot guarantee the security of the subscribed endpoint. For example, if we validate domain ownership when the subscription is created, it’s still possible that ownership of the endpoint URLs might change and thus leak sensitive information.
We would like to propose an option to include only the resource type and resource Id in the body; API consumers could then issue a GET request to get the content of the resource after receiving the subscription. This proposal adds an additional API call but avoids leaking additional sensitive information and helps enforce authorization and authentication logic against the FHIR server.
Thanks,
Da
Jens Villadsen (Nov 06 2018 at 00:42):
Seems sane - but if it is to be altered/extended/changed it might be worth the trouble to have a look if other fields would be worth exposing - all in control of the client creating the subscription by pointing out the wanted fields using FHIRPath expression as part the url- @Ewout Kramer ?
Grahame Grieve (Nov 06 2018 at 06:41):
that's why we say that servers might not allow this at all, or only allow it to whitelisted servers - see http://build.fhir.org/subscription.html#safety
Jens Villadsen (Nov 06 2018 at 10:31):
@Grahame Grieve while all kind of distribution of information in some perspective can be considered a security risk, would you classify the distribution a resource ID and resource type a security risk?
John Moehrke (Nov 06 2018 at 13:17):
Risk is one of those things that does not have a TRUE/FALSE answer. There is little risk if the resource ID is appropriately created. But yes if there is a pattern to the GUID that exposes some information, then the risk is higher.
Lloyd McKenzie (Nov 06 2018 at 14:05):
And if the id is a social security number or other well known real-world resource, the risk would be quite high indeed (which is one of the many reasons why real-world ids shouldn't be used for resource ids...)
Jenni Syed (Nov 06 2018 at 14:40):
Or if you've built your subscription in a way that makes that notification itself give away PHI
Jenni Syed (Nov 06 2018 at 14:41):
EG: subscribe to positive HIV results for patients... (again, servers may not allow this)
Da Huang (Nov 06 2018 at 15:15):
Thanks. In our case, the resource ID is a random UUID.
Kurt Ericson (Nov 06 2018 at 17:54):
I think the key thing we're trying to guard against is the case where domain ownership changes (for whatever reason) and thus a payload gets sent to an invalid entity. It's clear that server users want to receive some data (e.g. to support monitoring apps) and receive notifications for one or more subscriptions on a single endpoint so we'd like to support populated payloads. At the same time, we're trying to limit the risk of what's exposed -- e.g. by masking the payload to id/type. It's not perfect -- as others have mentioned -- but it helps de-risk the operation. (Perhaps masking with FHIRPath would be the way to go?) If someone created an endpoint like https://.../update-when-john-has-hiv it would clearly leak phi under a lot of logging/domain transfer scenarios.
John Moehrke (Nov 06 2018 at 18:44):
There are subscription types that don't leak any information in the notification. If you are concerned about the risk that rest-hook presents, then use websockets, which is client initiated connection with only a ping.
John Moehrke (Nov 06 2018 at 18:46):
Another risk that we have not talked about is that the resource ID is a unique identifier that will show up in many places. link all those places together and you start to create a re-identification risk. This has been mentioned in the FHIR spec, most specifically on http://build.fhir.org/person.html#security and also the Security page http://build.fhir.org/security.html#SecPrivConsiderations
John Moehrke (Nov 06 2018 at 19:10):
Even with rest-hook, the resource server calling the rest-hook endpoint should be validating the TLS server identity. Following IETF Best Current Practice for TLS (BCP195) it would also be confirming the Server Name Indication https://tools.ietf.org/html/bcp195#section-3.6... So the risk of domain ownership change is mitigated by good TLS (https) use. I would recommend a resoruce server not accept a rest-hook subscription that is not using a secured endpoint.
John Moehrke (Nov 06 2018 at 19:17):
I have identified this gap in explanation of rest-hook security risk in GF#19621
Da Huang (Nov 06 2018 at 20:25):
I think the question becomes: does the endpoint nominated by the user who has proved his/her authentication and authorization of the FHIR API automatically gets the authentication and authorization to receive FHIR resource content? I think the answer should be NO in most cases. Domain ownership change is only one of the potential problems, and I am afraid there are more other hidden security issues.
As a secure FHIR API, I think it should always check the user(endpoint)’s authentication and authorization before sending data out.
Da Huang (Nov 06 2018 at 21:01):
For the domain ownership change problem, it looks to me the solution requires the FHIR server to remember the TLS certificate of the endpoint when the subscription is created or updated, which sounds over complicated.
John Moehrke (Nov 06 2018 at 21:31):
Certificate pinning is what you are describing. It is an additional best practice. What Server Name Indication checks is that the site identified in the certificate (the certifcate was previously validated algorithmically and does chain to a trusted root) is the site you were attempting to connect to.
Da Huang (Nov 08 2018 at 15:36):
Sorry, I don’t quite understand how can Server Name Indication solve the domain lapse problem. I think certificate spinning could also not guarantee the owner of the endpoint always have the authentication and authorization to read resource content. A system that tries to tie endpoint control to data ownership is going to be brittle and seems especially problematic for PHI. Besides, there are certificates (e.g., Let's Encrypt) that change every 60-90 days, which makes (leaf) certificate spinning not practical to implement.
In addition, pushing resource content to an endpoint may cause authorization/permission issues, for example, the user who creates the subscription resource does not necessarily have the permission to read the resource content that is going to be pushed to the endpoint. Besides, the permission/role of the user could also change in time, which makes the FHIR server hard to check whether the endpoint has the right permission to receive the resource content.
All the above problems could be solved by just sending some (well created) pointer (e.g., resource ID) in the notification, and let the endpoint do another request to FHIR server with proper authentication and authorization check.
Grahame Grieve (Nov 08 2018 at 18:42):
indeed, which is why you can say not to send the payload
Kurt Ericson (Nov 08 2018 at 19:41):
I wonder if there is room for a proposal about some kind of middle-ground between send nothing (no payload) and send everything (the full resource). Clearly not intended for R4. :) I think we'd like to find a way to, long-term, have something in the middle too, even if just id and resourceType (or perhaps flexible like a resource mask with FHIRpath defined at subscription-time). Is that kind of idea something we could detail further and propose?
Grahame Grieve (Nov 09 2018 at 00:56):
sure. a profile? or _elements?
Jens Villadsen (Nov 09 2018 at 20:14):
So depending on your subscription needs and how long-lived they are ... - ain't this possible with the current design omitting payload? If you as the client create the subscription you are also in control of the endpoint. Since you can define the endpoint (and let that eg. end on something unique that you define - something session-like) AND you define the criteria and thereby the return type, you effectively know at the time the subscription triggers your client endpoint what the type is. Now, it is correct that you still do not know the resource ID, but that is found reissusing the &_since=:last as described in the documentation. This would at least get you half the way
Last updated: Apr 12 2022 at 19:14 UTC
