Application

5 Ways Healthcare Applications Leak EPHI

Protecting ePHI is one of the most important responsibilities assumed by all of us working in healthcare. Unfortunately we frequently find that applications still leak critical ePHI data, often in very simple and needless ways. Web applications that handle sensitive information need to do more than many people think to properly protect data. Although the issues mentioned here are not very technical or even critical in nature, they have far bigger implications in healthcare applications than most other industries.

Below are five of the most common vulnerabilities we see when conducting vulnerability assessments on applications handling ePHI:

1 – Protected Health Information in URLs

The majority of data handled by web applications is sent in one of two ways, with a GET or POST request. GET requests are commonly misused for handling sensitive information, in several circumstances they can easily allow for information to be disclosed to unauthorized parties. Below is a simple example of an application passing parameters in a GET request:

GET /showrecord.aspx?id=12345&name=JOHN+DOE&dob=12/12/1965 HTTP/1.1

Using this method, there are several ways that the patient’s name and DOB may be leaked to unauthorized parties:

  • URLs are cached in web browser history logs. Anyone with physical access to the machine may obtain data passed in URLs.
  • Data passed in GET requests may be visible on screen for longer than necessary and susceptible to shoulder surfing.
  • URLs may be cached by intermediate web proxies and viewed by unauthorized parties.
  • URLs may be cut and pasted by users and sent to other users.

Below shows the same request made with the POST method (avoiding the scenarios listed above):

POST /showrecord.aspx HTTP/1.1
[...]

id=12345&name=JOHN+DOE&dob=12/12/1965

Any HTTP request containing sensitive parameters should use the HTTP POST method.

2 – Improper Cache Controls

Web servers typically respond to HTTP requests with a number of headers; they are not visible to users, but they instruct browsers how to handle the content being sent. Among these headers are optional directives for how long data is to be cached. If web browsers are not explicitly told not to cache data, the content will often be stored locally, creating local files with potentially sensitive information available to anyone with access to that computer.

There are three main cache control headers that can be used to instruct web browsers as well as intermediate proxies on how data should be stored. Below is an example of the three required headers being used to prevent caching of ePHI:

Cache-Control: no-store
Pragma: no-store
Expires: -1

These directives can also be issued via Meta tags within HTML source; however, HTTP headers are the most effective and preferred delivery method.

3 – Poor Enforcement of SSL

Most applications handling ePHI have the good sense to use SSL for secure communication. While a properly configured TLS/SSL connection can keep data secure from third parties, we still find applications that are also available over plain-text HTTP. If users access the application by directly typing the ‘http://’ protocol, they may end up sending their credentials or session token over a plain text channel. This would allow anyone with physical access to network infrastructure between the user and server to view or modify the data in transit. Because of this, it’s important to remember that applications should forcefully redirect all users to HTTPS pages if accessed over HTTP.

Below shows an appropriate response to any page requested with an ‘http://’ prefix. Note the new location is over HTTPS.

HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Location: https://example.com/requestedpage.aspx

4 – Excessive Application Timeouts

Every secure application should expire user sessions after a certain length of inactivity. There’s no one fixed length of time that can be deemed appropriate for all applications, but we can do our best to use reasonable timeout periods. Industry standard timeouts range from thirty to 60 minutes, so unless there are specific usability concerns it is strongly recommended that sessions are expired within 60 minutes.

In addition to session timeouts, we strongly recommend that the application redirect users to a login screen when the session does timeout. This ensures that ePHI is not left shown on screen after the timeout.

5 – Insufficient Access Controls

Improper validation of user privileges often results in a user’s ability to read other users’ data or take complete control over the application. When applications perform authorization checks based on parameters supplied by users, rather than a secure session token, the server loses control over that operation. It is absolutely critical that every authorization check is performed by the permission granted to the session token granted to the user when their username and password were provided.

In the below example, a user makes a request to view their medical record. Their web browser passes four pieces of information to the application: a session token, a user ID, Name, and date of birth. It’s easy for developers to take the information they need from this request and display the medical record based on the user ID provided. Unfortunately the user ID parameter is trivial to modify by any moderately skilled attacker. This ID can also easily “brute forced” to make the same request for the next 10,000 increments with just a few clicks.

POST /showrecord.aspx HTTP/1.1
[...]
Cookie: SessionID=f427e90cc3b78024ebbd99a731ca1b4f;
[...]

id=12345&name=JOHN+DOE&dob=12/12/1965

Before any operations are performed, the application must validate the SessionID token provided by the user and ensure the operation requested is allowed by their privilege role. While any bypass of user privileges is a high risk issue, the severity of issues like this in healthcare applications carries even more weight. Patient portals and any patient facing applications with these types of vulnerabilities can quickly turn into a nightmare.

Conclusion

Technology in healthcare is advancing so rapidly that security is often an oversight. Building security processes into application development is critical for building robust and sustainable technology. We must remember that the protocols in which most of the internet was built on, have no security built in. Healthcare applications need to go far out of their way to compensate for the lack of security in underlying protocols. Healthcare organizations go through great lengths to protect PHI, we must ensure that applications have the same processes and checks to do their own due diligence.