Security considerations

The notification endpoint that subscribers specify in subscriptions for notification purposes is outside of the server's control and its security is the responsibility of the client implementor and the subscriber.

Notification endpoint security

The notification endpoint of the subscriber accepts notifications, which may be of malicious origin. The payload of such notifications can be categorized as follows:

• Invalid payloads that should get refused by the subscriber's endpoint.
• Valid payloads containing invalid (non-existent or non-accessible) resource ID-s, which will result in the subscriber making a request to the server for such resource ID-s and getting an error response.
• Valid payloads containing valid but irrelevant resource ID-s, which will result in the subscriber making a request to the server for such resource ID-s and getting such resources. The subscriber should recognize that the resources are not relevant for the subscription.
• Valid payloads containing valid and relevant resource ID-s, which will result in the subscriber making a request to the server for such resource ID-s and getting such resources. This should not pose a problem, since this is the way the system is supposed to work.
• Valid but empty payloads ("heartbeat" notifications) will not result in the subscriber fetching any resource.

The behaviors described so far alone do not allow achieving any malicious goals. However, there are additional aspects to consider:

• The receipt of any valid payload indicates that the notification mechanism is operational. By feeding empty or irrelevant notifications to the subscriber, it can be tricked into believing that the notification mechanism is operational even when it is broken.
• A denial-of-service type of attack could be attempted by overloading the system with a large number of requests. The client implementation should be able to mitigate this threat by throttling requests above some predefined rate.
• Malicious requests could attempt to exploit some other security vulnerability of the client implementation.
• Notifications also contain the subscription ID and an event number. Normally, receiving two notifications for the same subscription with the same event number indicates a repeated delivery with identical contents, therefore the second such notification is typically ignored. By feeding notifications with upcoming event numbers to the subscriber, it can be tricked into ignoring further notifications from the server. The client implementation can mitigate this threat by treating notifications solely as triggers and ignoring the resource ID-s in their payload. This means that when the client implementation receives a notification, it needs to fetch the events directly from the server.

These issues can also be mitigated by specifying a token to be sent in the notification headers for the purpose of identifying the origin of the notification. These tokens must not allow any other action than accepting notifications. The tokens should also be limited to specific endpoints so that even if a token for one endpoint gets leaked, it will not be valid for other endpoints.

In case a subscriber notices that an identification token of theirs got compromised, they must stop accepting it and generate a new token that need to be updated in the server too. This is made possible by the modification operation of subscription resources that allows changing the notification endpoint and the notification parameters.

Misconfigured subscriptions

If a subscriber accidentally or maliciously specifies a wrong endpoint, then all notification content will be delivered to that endpoint. This includes both the notification payload and the so-called notification parameters, which are HTTP headers specified by the subscriber.

Examples:

• A subscriber may specify an endpoint with a typo such as https://hosiptal.org/notifications instead of https://hospital.org/notifications. If a malicious actor had registered the domain hosiptal.org beforehand, notifications will be delivered to them.

• A subscriber may specify an endpoint with some PHI (personal health information) in a URL parameter such as https://hospital.org/notifications?subject=JaneDoe&condition=childbirth. If the hospital.org domain expires and a malicious actor buys it, notifications will be delivered to them. Regardless of the actual contents of the notifications, the malicious actors will be able to extract information from them because the URL parameters leak personal information and/or the nature of the medical event/condition.

• A subscriber may specify a notification parameter with credentials in them, such as Authorization: Bearer VGhpcyBpcyBub3QgYSB0b2tlbi4K. In the endpoint-with-typo scenario above, these credentials would get delivered to the malicious actors, who can exploit them for their interaction with the real system (see compomised endpoints above).

Server-side mitigations

To mitigate the risk of PHI leakage through the notification payload, the server employs the following strategies:

• The payload of the notifications is limited to the ID-s of the resources.
• The resources that notifications could be sent about have meaningless ID-s.
• Before notifications are sent, the endpoints are checked against an explicit allow list maintained by Roche personnel.

Client-side mitigations

To prevent the leakage of PHI and credentials through notification parameters and URLs, client implementors need to take precautions. Implementors need to consider that any information included in the notification parameters or the endpoint URL will be sent to the endpoint if it is on the allow list, even if the information is incorrect. Therefore, clients must ensure that no PHI or authentication credentials are included in these parameters. If an identification token is set up to be sent in the notification headers, it must not allow any other action than accepting notifications and it should be limited to a specific subscription or at least to a particular endpoint URL.

To mitigate this risk further, client code should not allow client employees to specify arbitrary notification endpoint URL-s for subscriptions.

Client-side mitigations are the responsibility of the client implementation and operational policies.

Recommendations

Based on the above, the following best practices are recommended to implementors:

• Ensure that no PHI or authentication credentials are included in notification parameters.
• Do not allow employees to set arbitrary notification endpoint URL-s.
• Consider directly fetching the events from the server in response to a notification, thereby treating the notification solely as a trigger and ignoring the resource ID-s in its payload.
• Specify a token as a notification parameter to be used for identifying the origin of the notification.
  • The token needs to be considered as a means for identifying the sender of the notification and not for authenticating the sender of the notification.
  • The token must not allow any other action than accepting notifications.
  • The token should be limited to the specific subscription, or at least to the specific endpoint URL.
  • If you use tokens with limited validity periods, regularly update the subscriptions, replacing the tokens with fresh ones before they expire.
  • If a token gets compromised, immediately stop accepting it and update the subscription with a fresh token.
• Do not include any meaningful information in the endpoint URL nor in the notification parameters (including the contents of the token).
• Rate-limit notification endpoints to prevent denial-of-service attacks from malicious actors.