Security vulnerabilities in C-CDA Display using CDA.xsl

Today, Josh Mandel posted a security report about CDA.xsl which is an example Stylesheet used by HL7 to illustrate how to generate HTML from a CDA document.  The example XSLT has several security holes which can be taken advantage of by an attacker when a system blithely uses it to display a CDA document without first checking to be sure that it is valid according to the CDA standard.

I won't spend to much time on the details since Josh covers them rather well and also did so quite responsibly.  There are two quick fixes against the attacks, an additional attack he didn't mention which is that the referrer attack (his third attack listed) may also be used against the <IFRAME src=''/> content produced by the sample stylesheet.

So let me briefly outline three mitigations, and note that these are not the only ones you might use, and that more analysis is probably needed (the danger of providing a partial solution is that people who have been burned once by using someone else's work can all into that trap again.  Learn your lesson and investigate further):

1. Prevent any output of a src or href attribute in the HTML that doesn't resolve to an http: or https: path. Better yet, don't use IFRAMEs.
2. Validate any CDA document against the CDA schema supplied by HL7 before you display it, and refuse to display an invalid document without first confirming with the end user that this document may result in a system compromise (in case it is really an essential document for patient care).  This has the effect of preventing documents containing the invalid content from being able to generate unexpected attributes.
3. Don't use a browser control you don't have full security control over to display your documents.  Be sure to configure the controls that you do use to NOT generate Referrer headers.  And don't include private state information in your URLs that can be used to attack your system.

And more importantly, the lessons learned from this experience which HL7 or any other SDO should consider:

1. HL7 published code samples should go through the same kind of analysis and testing that real world code goes through because it is likely seen to be authoritative.
2. Any HL7 published code should clearly note that it is the recipient's responsibility to ensure that appropriate security precautions are taken when implementing the code.
3. Someone should be identified as being responsible for identifying and addressing security issues related to the standard, and these should be published in the standard.  IETF and IHE already have procedures that ensure this occurs.  
4. The HL7 TSC should approve some policies in this area and specific guidance on security issues related to these sorts of examples, and the HL7 Security Workgroup should make some recommendations to the TSC for their approval.

And one some additional one for anyone (Vendor or Provider) using SOUP (Software of Unknown Pedigree).  You have a responsibility to your end users to ensure your product is secure.  That means that if you don't understand the security risks associated with SOUP, you need to do the analysis yourself and be sure that appropriate security precautions are taken.  

Thanks Josh for finding this, and for taking a very responsible and difficult route to ensure that everyone was notified.

For those of you readers who need a fix: the analysis above is incomplete.  At best it serves as a quick patch if you are just learning about it which you can use to mitigate the issues until you investigate further.

Keep up with Josh's additional posts because his work will be more complete, and I hesitate to duplicate it^*. I can hardly do better than someone who has been so well recognized for his contributions to standards, twice now.

   Keith

P.S.  Congratulations Josh, you are the first and probably last to receive those two awards (unless John decides to have a different policy).