Stream: Security and Privacy
Topic: Cardinality infinite
Peter Osburg (Oct 01 2021 at 04:54):
Hi,
I am currently in a discussion with a security expert of my team that is new to FHIR. He is wondering why in FHIR there are so many fields with an infintie cardinality (like 0..* or 1..*). His argumentation is that any data structure allowing infinite entries is a potential security risk or potential attack vector for at least DOS attacks or XML bombs.
I was trying to mention that in my opinion these security risk have to be handled on application level (or server in that case) but not on the semantic level (like FHIR). I couldn't fully convince him as we were looking at a resource having a name field whereas it would be allowed to have 1..* first names. Obviously no one is having an infinite list of first names, or to be more on the medically reasonable level: no one would ever have an infinite number of diagnoses.
I wasn't able to give him proper argumentation to not artificially restrict the cardinality on FHIR level and therefore like to ask you: Do you know of any risks or attack vectors related to an infinite cardinality in FHIR? Or do you know if discussion on this topic can be found somewhere else?
Any help is appreciated. I mean, could he also be right? And when it comes down to profiling resources for certain use cases we should always aim to get rid of an infinite cardinality?
Grahame Grieve (Oct 01 2021 at 04:55):
well, obviously no system is going to support infinite anything.
Grahame Grieve (Oct 01 2021 at 04:56):
so infinite means, defer to system judgment. Clearly a system should protect itself against denial of service attacks.
Grahame Grieve (Oct 01 2021 at 04:56):
he sounds like a good security guy: obsessed about everything. But the standard won't solve that particular problem for him
Peter Osburg (Oct 01 2021 at 05:01):
Thx for the compliment :)
But am I reading you correctly that you would not suggest to artificially restrict the upper limits while creating profiles for certain use cases?
Lloyd McKenzie (Oct 01 2021 at 05:09):
If you're defining a profile for a specific system that has particular limitations, or you've got community agreement that "We will not support more than 5 given names for a person", you could specify a max. However, specifying maxes in many places interferes with interoperability. If you set a max of 2 given names, and some real person has 5 and a sending system needs to send all 5 because other recipients want and need all 5, they're suddenly faced with building a separate interface for your system that blows up if there's more than two. On the other hand, if you create a profile with a sanity max of 100, then everyone panics about the fact you said they need to support up to 100 given names (and some certifier out there will probably try to fail you if you don't display all 100).
General guidance is "accept what you can handle, don't blow up if there's more than you need if it's safe to ignore the extras, and protect yourself against whatever you deem to be a dangerous quantity." (Dangerous for a smartphone app might be different than a back-end server.)
John Moehrke (Oct 01 2021 at 14:46):
All of this is well-known in the security community as "Robustness Principle". Any system design will make decisions on upper limits, and they need to be defensive against attacks to that upper limit. Some will choose a hard integer, others will choose a buffer-space limit. It is a system-design choice on how one is Robust.
John Moehrke (Oct 01 2021 at 14:47):
Your security expert is right to point this out. I would simply leverage this point into Systems-Design discussions.
See point #11 on the security page - http://hl7.org/fhir/security.html
John Moehrke (Oct 01 2021 at 14:49):
FHIR as a core-standard is simply a standard. As Lloyd and Grahame have expressed, any upper limit we place will have equal negative reactions (that is too big, that is too small). The only way to get this right in a core-standard is to leave it unbounded and encourage good Implementation Guide considerations, and good systems-design.
Brian Postlethwaite (Oct 03 2021 at 21:59):
I'd expect that the limitation is not in the single element cardinality (usually) but in the message (or request/response) size as a whole instead. Which is set at the infrastructure layer.
Last updated: Apr 12 2022 at 19:14 UTC
