CDA Security Issues and implications for FHIR

Overnight, Josh Mandel posted several security issues with regard to CDA:

This blog post describes security issues that have affected well-known 2014 Certified EHRs. Please note that I’ve already shared this information privately with the Web-based EHR vendors I could identify, and I’ve waited until they were able to investigate the issues and (if needed) repair their systems.

Josh identified 3 issues:

  1. Unsanitized nonXMLBody/text/reference/@value can execute JavaScript
  2. Unsanitized table/@onmouseover can execute JavaScript
  3. Unsanitized observationMedia/value/reference/@value can leak state via HTTP Referer headers

So how do these relate to FHIR?

  1. The nonXMLbody attack as described by Josh is an accident in the stylesheet. The real problem is that a nonXMlBody can contain unsanitized HTML of any type, and there’s no way to show it faithfully and securely.Impact for FHIR: none. FHIR already includes native HTML, and active content is not allowed
  2. This and lots of other attacks are possible – though illegal – in FHIR.Impact for FHIR: we need to tighten up the base schema, the reference implementations to reject this content (and also document that this is a wonderful attack vector, and systems must validate the resources)
  3. This is by the far the hardest of the issues to deal with; as an outright attack, any system processing resources must ensure that http headers – including the http referer header – don’t leak when the image is retrieved. But there’s a more pernicious issue – if you author a CDA document, or a resource, you can insert a uniquely identified image reference in the source that means you get notified every time someone reads the document – kind of a doubleclick.net for health records. This is a different kind of attack again.Protecting against the second kind of abuse is only really possible if you whitelist the set of servers that are allowed to host images you will retrieve. My suggested whitelist: empty. Don’t allow external references  at all. In practice, that’s probably too draconianImpact for FHIR: provide advice around this issue. We can’t make it illegal to provide external references, but all implementations should start at that place

Whitelist of allowed HTML elements and attributes in FHIR

I am updating the FHIR xhtml schema, the java and pascal reference implementations, and my server, so that they only accept html elements with these names:

  • p
  • br
  • div
  • h1
  • h2
  • h3
  • h4
  • h5
  • h6
  • a
  • span
  • b
  • em
  • i
  • strong
  • small
  • big
  • tt
  • small
  • dfn
  • q
  • var
  • abbr
  • acronym
  • cite
  • blockquote
  • hr
  • ul
  • ol
  • li
  • dl
  • dt
  • dd
  • pre
  • table
  • caption
  • colgroup
  • col
  • thead
  • tr
  • tfoot
  • th
  • td
  • code
  • samp

The following attributes will be allowed:

  • a.href
  • a.name
  • *.title
  • *.style
  • *.class
  • *.id
  • *.colspan (td.colspan, th.colspan)
  • img.src

Have I missed anything?

5 Comments

  1. Peter Jordan says:

    As I read Josh Mandel’s article, the 3rd issue will only manifest itself if session state is passed in URLs (particularly if not encrypted). One wouldn’t expect to see that technique used in a RESTful API like FHIR.

  2. Grahame Grieve says:

    There’s a lot of other ways for this to manifest as a problem. This isn’t really about issues across the FHIR API, but about what happens downstream from it if a system is using the HTML

  3. Peter Jordan says:

    Well you did pose the question as to how this relates to FHIR, Grahame. 🙂 The issue about consuming HTML is a generic one that boils down to security policies and trust models. If any eHealth application is about to generate HTML from an untrusted source, best it scans that markup text before it’s rendered. One would also hope that Healthcare Facilities have very tightly-configured browsers.

  4. Larry Singer says:

    There also needs to be protection against javascript in a.href and img.src.

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen

*

%d bloggers like this: