Security Tips for HealthVault Application Developers jim.oleary software.security.engineer health.solutions.group

(1)

1

Security Tips for HealthVault

Application Developers

(2)

2

Introduction

Hello, there! Welcome to the HealthVault Partner Security Guidance Document – a hodgepodge of recommendations, warnings and best practices that you should apply to your HealthVault application development cycle. As a reader of this document, you’re likely a potential HealthVault developer, a security professional assessing the robustness of a HealthVault application, or some nefarious hacker looking to compromise valuable health data. In the latter two cases, you are already familiar with many of the issues outlined here, since most of these threats are shared across all web applications and are not specific to HealthVault.

Like any public security guidance, this document could effectively be renamed to “How to Hack a HealthVault Application”, as the technical details that follow can be used for both good and evil. You should treat this collection of threats as the minimum set of attacks that your application will be exposed to. You can find more information on particular threats through a simple web search or via the resources mentioned at the end of this paper.

Security Process

One of the most important rules in development is that security must be factored into every decision at every point throughout the lifecycle of your application. Reading this document right before going live with your application will do little more than open your eyes to all of the potential threats that should have been acknowledged and designed against since your project began. Microsoft abides by and recommends a structured Security Development Lifecycle for all software projects; in the ideal case that you are reading this document during the early stages of your project, it will be extremely valuable to become familiar with and adopt a similar model for the development of your application. With that said, let’s head into some of the more technical aspects of securing your applications.

(4)

4

HTTP vs. HTTPS

For starters, any sensitive communication between your users and application must be over a secure channel. All user data sent to or from the HealthVault platform service or the HealthVault Shell is sent over an encrypted channel at all times [see Figure 1]; however, if an application establishes an insecure connection with a user, malicious third parties may be able to view or manipulate sensitive health information as the bits travel across the Internet.

HealthVault Shell HealthVault Platform HealthVault User HealthVault Application Prying Eyes SSL SSL SSL SSL HTTP / HTTPS?

Figure 1: Data Transmission within HealthVault Applications

Extended Validation SSL certificates are available from several certificate authorities, and couple with developments in browser UI to provide additional identity information to site visitors. This can be a valuable asset in gaining user trust, but is not a technical necessity for establishing a secure

communication channel [see Figure 2]. When configuring SSL for your application, ensure that your server is negotiating only secure protocols and ciphers when establishing encrypted communications channels – otherwise, it might be possible for attackers to intercept messages that establish the secure channel, and downgrade or eliminate the cryptographic algorithms that protect your data in transit (for more information, search online for “SSL downgrade attack”).

Figure 2: Sample address bar from a browser visiting a site with an EV cert

While an important security baseline, it’s crucial to note that simply using SSL will not protect you from almost any of the additional threats outlined in this document. Securing communication is one thing, securing your application another.

(5)

5

Cross-Site Scripting (XSS)

Probably the most common web vulnerability, and certainly one of the most damaging, cross-site scripting bugs allow third parties to inject arbitrary code into the context of your website. Browsers render the attacker-supplied code as if it were legitimately provided by your web application, giving script the ability to steal user cookies, make AJAX calls on the user’s behalf, instantiate sitelocked ActiveX controls, etc. You can find more doom and gloom reasons as to why XSS is something you absolutely want to keep out of your HealthVault application in the Resources section, but we’ll focus here on some things you can do to prevent/mitigate XSS in your site.

Place Restrictions on User Input / ASP’s ValidateRequest

One of the first steps you can take in protecting your site from XSS attacks is to limit the character set allowed as input to your application. For example, a date or medication name submitted to your application will typically conform to some regular expression. I’ve yet to meet anybody with

“<script></script>;javascript:alert();’<>%0D%0A%00&’;--“ on a birth certificate or driver’s license, yet most sites will gladly accept such a string as a valid user name. Good developers will encode user input before passing it back to the browser; however, as a codebase grows it often becomes difficult to track a piece of data across all of your pages – that questionable value that you accepted earlier can easily make its way into a new line of code from a developer unfamiliar with all of the possible values. Ask yourself, “what should I accept from users?”, and enforce checks on both the client (JavaScript is one easy way to provide convenient validation for users) and server side (much more important!!) of your application. ASP.NET’s ValidateRequest feature provides a baseline protection against malicious input, and should be enabled by default; however, you should not rely on this feature alone to protect your application – proactively code against malicious input.

Encode Data on Output - AntiXSS Library

As described in the previous section, your application is inevitably going to receive some malicious data. It’s up to the developers to maintain site integrity, no matter what input the code may be handling. This typically means HTML or URL encoding externally-provided input, so that user-supplied data is not directly embedded into site code. For example, the value “<script>” would become

“<script>” or “<script>” when rendered back in the page source, allowing for the correct characters to be displayed to the user, without the browser treating the value as input to be parsed. Microsoft has released the AntiXSS Library [V3.0 Beta] [V1.5] as a resource that developers can use to encode output and protect applications from XSS threats.

Protecting the Contoso Bookmark Page contains a great practical walkthrough, showing integration of the AntiXSS library as a means to fix up an otherwise insecure site.

Mark Cookies Secure; HttpOnly

Defense in Depth is a great design principle, which you should be applying throughout your application development already. In that vein, there are several steps you can take to further protect user cookies from leak or compromise. The first such mitigation is the addition of the ‘secure’ flag to any sensitive cookie set by your website. This attribute instructs the browser to send the cookie to your server only

(6)

6

when communicating over a secure channel. Without this setting, sensitive authentication information will be sent with requests to both https://www.your_healthvault_site.com and

http://www.your_healthvault_site.com (even if no such site actually exists), exposing credentials to the threats covered in the earlier HTTP/HTTPS section.

The HttpOnly attribute instructs the browser to protect the cookie from client-side script, so that exploit code for an XSS vulnerability is unable to access sensitive session information stored in the cookie. With that being said, there are plenty of other nasty things an attacker could do when exploiting an XSS hole, so while setting the HttpOnly and Secure attributes on your cookies is a great best practice, the best approach is keeping XSS bugs out of your code in the first place.

Cross-Site Request Forgery (XSRF)

Somewhat similar to XSS, but almost entirely different, cross-site request forgery vulnerabilities allow attackers to issue authenticated, but unauthorized, requests to your web application. Whereas an XSS exploit will attempt to steal a cookie so that the attacker can hijack an authenticated connection, XSRF takes advantage of users that have already logged in, forcing them to issue authenticated requests against the server. A classic example is a financial trading site, where money transfers are handled by a SendMoney.aspx page, which takes a destination account number and transfer sum as querystring parameters. As an attacker, I can force the user to issue a GET request to the server (either via a direct phishing link, hidden iframe, img src or any variety of tricks), with the account and sum information prepopulated (https://www.your_insecure_bank.com/SendMoney.aspx?target=1337&amt=500.00). If the victim is currently logged in, the request will be handled in the context of that session, and the server will make the fraudulent transfer. Attackers can easily craft arbitrary POST requests as well, so don’t get lured into a false sense of security if your application doesn’t rely on GETs to perform privileged operations. User Good Website Bad Website

1. User visits malicious site

2. Bad Site HTML embeds Request to Good Site 3. Browser issues request on User’s behalf

(7)

7

Canaries/ViewStateUserKey

Sometimes referred to as canaries, per-request unique values protect users from XSRF attacks. In practice, the server generates a random value, passes it to the user as a hidden form variable or part of the querystring, and only processes an authenticated request if it contains the same value that was sent down earlier. Strong canary values are unique to an individual user, session and request – so that they remain unguessable and non-replayable if they should ever leak via a session that has been

compromised through some other vulnerability (like XSS). Using the previous bank example,

SendMoney.aspx would ideally move to a POST request, with a unique value passed into the form as a hidden variable, and verified on PostBack.

User Good

Website

1. GET request to Good Site 2. Response HTML includes unique value

3. POST request contains unique value

Figure 4: Sample canary implementation

ASP’s ViewStateUserKey provides token generation/verification for your pages, and should be

implemented across your site. You should note that ViewStateUserKey does not protect GET requests, in which case developers must add a querystring parameter containing the canary themselves. Note that performing privileged actions through GET requests can be risky for other reasons, such as client-side “web accelerators” prefetching pages that cause server-side state changes.

Arbitrary Redirection

Another very common problem in web applications is an ability for users to visit a URL on one domain, and be instantly redirected to another without notice or interaction. Due to the redirect logic used in authentication, this issue is particularly relevant to HealthVault applications.

Phishers, scammers and other ne’er-do-wells will take advantage of this weakness to trick users into visiting fake sites that appear to have valid origins on your domain. Users have been educated to be wary of links that point to suspicious-looking domains, but are generally willing to follow links to microsoft.com, healthvault.com, etc. An open redirection vulnerability allows phishers to embed and send valid-looking links that will redirect to malicious sites. A common trick is to URL encode querystring parameter values, such that

https://www.your_healthvault_site.com/r.aspx?r=http://www.hacker_site.com looks like https://www.your_healthvault_site.com/r.aspx?r=

%68%74%74%70%3A%2F%2F%77%77%77%2E%68%61%63%6B%65%72%5F%73%69%74%65%2E%63%6F%6D

To protect your site against this threat, developers should review all redirection code and implement an IsValidURL method to verify that the user is being redirected to a trusted or intra-domain destination

(8)

8

that is appropriate for the application. Currently, the HealthVault SDK does not include a standardized method to do this, so you are responsible for developing your own.

Should Your Application Really Trust Data Coming From HealthVault?

We’ve already discussed how your application should handle untrusted input coming directly from the user, but a common misconception amongst HealthVault developers is that all data coming from the platform is to be trusted as non-malicious. If you look “up the stack” to where this data frequently originates, you’ll see that – you guessed it – your application is ultimately working with information that began as user-supplied input. Additionally, the HealthVault ecosystem allows users to share their data across multiple applications, many of which might be placing different restrictions on input, or making different assumptions about use cases. You can trust the HealthVault platform to maintain the integrity and privacy of your users’ health information; however, this protection applies to bad data as well as good. The user is ultimately in control of the data, and HealthVault applications should be developed to safely display any information – whether it comes directly from the user via the querystring, or indirectly through the Platform.

HealthVault Application A HealthVault Application B HealthVault Platform <script>document.cookie.. <script>document.cookie.. HealthVault User <script>document.cookie..

(9)

9

Digital Signatures

While on the topic of data integrity in the platform, it’s worth spending a little time on the digital signature support that HealthVault offers. As stated before, you can trust HealthVault to securely store your users’ health data, but the user has complete control over what information is shared or used with any set of applications. This leads to the following potential scenario:

- Application A creates and uploads DataItem X - Application B modifies the value of DataItem X - Application A fetches DataItem X

This could become an attack vector, as discussed in the previous section, but the more common case is that the item has been legitimately modified to reflect an updated condition in the user’s health record. This data fluidity is a huge benefit to working with the HealthVault ecosystem; users manage their individual health records, and applications get to work with the most up-to-date information, even if another application updates the data. However, you could imagine some cases where an application would like some assurance that the data it entered into HealthVault had not been modified before acting further on that data (example: a Doctor’s office places a prescription in HealthVault, and a Pharmaceutical application wants to ensure that the prescription has not been modified when fetching the data).

Digital signatures provide a cryptographic solution to the “did someone touch my data?” problem. The HealthVault platform uses the XML Digital Signature standard for signing data, and I would recommend spending some time familiarizing yourself with both the standard and general information on hashing and public-key infrastructure before using signed data in your application. As most of the information around signing and certificates is not HealthVault specific, we’ll leave most of that information out of this document, and focus on some more unique issues.

When uploading a signed piece of data to the HealthVault platform, the signature is calculated and verified, and the certificate is validated using expiration and revocation information provided by the issuing certificate authority. If either of these steps fails, your application will be unable to successfully store the item in HealthVault. As of the writing of this document, the HealthVault platform accepts data signed with certificates issued through VeriSign, Comodo, Entrust, and GeoTrust.

Signing a HealthVault item through the SDK is as easy as calling Sign()on a HealthRecordItem, and passing in an x509Certificate2 object before adding the item to a record. When fetching the data, specifying the HealthRecordItemSections.Signature section will pull down any existing signature information, upon which .IsSignatureValid() and .ValidateCertificate() may be called. Note that another application may have modified and signed the data as well; simply calling

item.ValidateCertificate()without any further inspection may lead to an inaccurate trust decision in your application. Also, consider including some date or unique identification in the body of the data to be signed – a signed item that consists only of “Please issue 500 mg of painkillers” could be shared or

(10)

10

copied between records, while maintaining cryptographic signature integrity. If you’ve left this section more confused than when you began, please check out this much more eloquent MSDN post on signing.

Logs, Caching and Data Sanity

We have talked a bit about data sanitization in the previous sections; how input should be restricted and output encoded to protect your application from a variety of threats. Data sanity is a different concept, which could be loosely described as “make sure you do the right thing with your users’ health

information”.

Careful Where You Put Those Files!

The biggest motivator behind this section is applications that take some information directly from the user or HealthVault, store it in some intermediate location, but forget to secure or maintain the

temporary storage. Examples include document upload features that store a local copy of the file before pushing the data to HealthVault (where the local copy happens to be a publicy-accessible web directory) and a charting site that would analyze user data, create a unique graph for the particular user, and push the image down over a URL similar to http://www.risky_health_site.com/graphs/00001.jpg (as you might imagine, there was no authorization check performed on the GET, and the next user would have information charted out in 00002.jpg). For the most part, these issues stem from poor design decisions or site configurations, and are often not the results of coding mistakes alone. Keep this class of issues in mind when reviewing your application for potential security problems. Review the attack surface of your application, and ensure that private data is safeguarded through policy and technical restrictions. Operationally, ensure that the private key associated with your HealthVault application is only deployed to your production servers, is never stored in the same directory as your application files, and is backed up in a secure and auditable location. More to the point, DO NOT EMAIL YOUR .PFX FILES TO

MICROSOFT WHEN TROUBLEHSOOTING! Unfortunately, this has been a common mistake that many of our early partners have repeatedly made during the go-live process. By design, email is an inherently insecure protocol – it travels in plaintext around the Internet, and is often long-lived once reaching its destination (you can probably find email from over 10 years ago in some of your inboxes). Moreover, if your application uses offline authorization to access information in HealthVault, you are putting your entire userbase at risk of medical data theft or corruption. The HealthVault platform has procedures and logic in place to safely suspend applications suspected of a private-key compromise, but these steps place an undue burden on our operations team, your application development team, and all of your users – best to keep those keys safe!

POST vs. GET

An issue that appears as trivial as deciding on which HTTP verb to use for a particular request can actually have long-lasting impact on data retention and leakage. Already discouraged for behavior outlined in the Cross-Site Request Forgery section, GET operations will typically expose more data in browser, proxy and web server logs. Sensitive information should be transmitted via form parameters in a POST request, so that the URL (that will end up in client and server-side logs) does not contain data

(11)

11

that can linger outside the context of the original session. Research “JavaScript History Stealing Attacks” if you’re interested in additional reasons as to why request verbs matter.

Stay Current with Security Patches

Frequently, developers will rely on an external piece of code or library for some certain functionality within the context of their application. From a security perspective, this added code offers another attackable piece of software and additional risk to the overall security of your application. Make sure that you have reviewed any assumptions that the external feature might be making in regards to security, and always keep up to date with the latest security patches. This applies to the machines that host your application as well – review the attack surface of your hosting environment, and ensure that all components are up-to-date with the latest security patches. Without doing so, your super-secure, impeccably-coded application may be compromised due to an exploited issue in the underlying operating system or web service software.

Defense in Depth

Lastly, you should take a layered approach in applying security to the design of your HealthVault application. Assume the worst scenario, and develop your application to react in a way that preserves data integrity and privacy. For example, the HttpOnly flag might appear unnecessary for a site claiming to be free of any XSS holes; however, browser or underlying hosting platform issues, external to code written by your developers, could lead to an XSS threat that would be further mitigated by setting the attribute on your site’s cookies. In software and security, things can and do get compromised in ways that the original developers never realized – robust, secure software is designed to account for the ever-changing threat landscape.

(12)

12

Contact

Questions/comments on this document [email protected] Report a Security Issue with HealthVault or a

HealthVault Partner

[email protected]; [email protected]

Resources

The Microsoft Security Development Lifecycle

Writing Secure Code, Second Edition – Michael Howard and David LeBlanc Take Advantage of ASP.NET Built-in Features to Fend Off Web Attacks OWASP – Application Security Community: Tools, Reading, and More

HealthVault MSDN Forums – Ask security questions; interact with the HealthVault development team

Document History

10.16.08 – Internal presentation of a set of security issues common across many HSG applications 03.20.09 – Reprioritized this document

03.26.09 – Distributed internally for review (small group) 04.07.09 – Shared with a small subset of HealthVault Partners 06.01.09 – Brushed up for a v1 launch

(13)

13

Appendix: HealthVault Application Security Checklist

Did you design against, develop to prevent, and test for the following potential/likely vulnerabilities??

Attack Mitigations

Cross-Site Scripting (XSS) _ _{Restricting User Input? Client}_and_{server side?}

 Encoding User-Supplied Output?

 Encoding data coming from HealthVault Platform?

 Enabled ValidateRequest on your pages?

 Marking cookies Secure; HttpOnly?

Cross-Site Request Forgery (XSRF) _ _{ViewStateUserKey or similar canary logic implanted?}

 POSTS instead of GETs where appropriate? Information Disclosure / Tampering _ _{SSL Everywhere?}

 Restricted HTTPS ciphers and protocols?

 POSTs instead of GETs where appropriate?

 Temporary Data stored in secure locations?

 Sensitive information removed after session logout? Spoofing / Phishing _ _{All logic reviewed for arbitrary redirection?}

 Redirection “whitelists” in place?

This list is by no means complete; other issues (like SQL Injection, Denial of Service, ClickJacking, XPath Injection, Integer Overflows, etc) may linger in your application as well. The resources contain more information on these threats, as this document hopes to only call out the top offenses in HealthVault applications.

Security Tips for HealthVault Application Developers jim.oleary software.security.engineer health.solutions.group