Healthcare.gov: Affordable Care should be Secure Care

Healthcare.gov is undoubtedly the most important site of the week. The site handles the sensitive information of millions of Americans: health history, identity, tax records and more. A project this important, naturally, is attractive to both security researchers and malicious attackers looking to identify security issues. The only difference is that security researchers stick to passive analysis and malicious attackers look for ways to exploit what they find. In this post, we will outline three quick observations that would encourage a malicious attacker to try to exploit the site. While these observations don’t indicate that the site already has any major vulnerability, they are red flags and, given the potential benefit, an attacker has plenty of motivation to explore further. A site this public and this important should follow security best practices from line one of code and configuration.

  1. Access-Control-Allow-Origin: * This header is a part of an HTML5 Cross-Origin Resource Shring (CORS) feature, enabling sites to do cross-domain communication. The header is used to restrict the domains that can make an AJAX request to healthcare.gov and access the content of the response. A value of “*” for this header indicates that any site can initiate a request to healthcare.gov and receive the response. We could not access authenticated area of healthcare.gov (the site was overloaded) but if this is the policy applied to any authenticated page of the site, it could expose the site to serious threats like Cross-Site Request Forgery (CSRF). Failing to restrict cross-domain communication can allow a malicious site to send requests, including POST requests, to healthcare.gov on victim’s behalf and gain access to his health records, and possibly enough information to steal his identity. Healthcare.gov should reconsider enablement of CORS feature on this site. Any required cross-domain functionality should be moved to web services. If that is not possible, they should restrict the value of this header to specific domains and specific functionality.
  2. No X-Frame-Options header: The X-Frame-Options header offers protection against Clickjacking attacks. Clickjacking is an attack where the attacker deceives a user into clicking an hidden element on a web page instead of the intended visible element. A successful clickjacking attack could disable certain security protections and submit a form on user’s behalf. Many sites implement frame-busting logic, a JavaScript solution, to protect against clickjacking. However, the introduction of the iFrame Sandbox attribute in the HTML5 specification has rendered that approach useless. To our surprise, healthcare.gov does not deploy any defense and the site can be easily framed inside an HTML iFrame tag. 
  3. Missing HTTPOnly and Secure flags for Cookies: These HTTP header attributes protect the theft of cookies using JavaScript injected through Cross-Site Scripting or other flaws. The flags instruct the browser to prevent cookie access via JavaScript, preventing an attacker from stealing any sensitive information stored in the cookie, such as the session ID. Healthcare.gov uses cookies to maintain user history on the site and user identification. However, it is not known whether the user identification is used as session identification too. Regardless, a user’s search history or visiting history could reveal sensitive information such as the possible health issues, income level, and marital status. Healthcare.gov should employ these flags to protect cookies. 


This is a very important site for a lot of people and, no matter how challenging it is to keep up with demand, security should never be put on the back burner. A site built upon the principals of security is naturally more reliable.

 

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation