Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

5 Obamacare Health Site Security Warnings

Early shakedowns of the health insurance exchange websites show they are vulnerable to cross-site request forgery, clickjacking and cookie attacks, among other risks.

9 Android Apps To Improve Security, Privacy
9 Android Apps To Improve Security, Privacy
(click image for larger view)

Are the health insurance exchanges -- aka "Obamacare" -- websites mandated by the Affordable Care Act safe against online attackers?

After the exchanges, also known as health insurance marketplaces, debuted Tuesday, users reported difficulty using them, to either price or sign up for insurance. At the federal level, White House officials blamed the glitches -- which persisted throughout last week -- on the large number of visitors to healthcare.gov, which saw 4.7 million unique visitors in its first 24 hours, and 9 million in total by Friday.

Sunday, however, federal officials admitted that healthcare.gov would require both code-level improvements as well as increased server capacity. "We can do better and we are working around the clock to do so," Department of Health and Human Services spokeswoman Joanne Peters told The Wall Street Journal. Forthcoming improvements will reportedly include both software and hardware changes.

[ Find out how Obamacare could change how companies offer health insurance to employees. Read Obamacare: The Rise Of Private Health Insurance Exchanges. ]

To that list of fixes, however, the federal government -- which through healthcare.gov is currently supporting or running health insurance exchanges for 36 states -- and 14 states that are running their own exchangesmight want to add a handful of information security improvements.

Here are five top concerns:

1. All-Access Request For Other Sites

According to Nidhi Shah, who works on research and development for HP's Web Security Research Group, healthcare.gov uses an HTML5 header that allows any site to make an AJAX request to healthcare.gov, then see a response. "We could not access [the] 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)," Shah said in a blog post. CSRF attacks, which have a place on the SANS list of the 25 most dangerous software errors (at #12), refer to trickinga targeted website into disclosing sensitive information.

2. Clickjacking Threat

The second major healthcare.gov security concern is the site's lack of clickjacking defenses. Using clickjacking, an attacker could overlay invisible elements on the legitimate website, so that, for example, if a user clicked what appeared to be a real link, it might run a malicious script instead. "To our surprise, healthcare.gov does not deploy any defense and the site can be easily framed inside an HTML iFrame tag," Shah said. In the past, many websites have used JavaScript "framekillers" to mitigate this type of vulnerability. "However, the introduction of the iFrame Sandbox attribute in the HTML5 specification has rendered that approach useless," she said.

3. Cookie Theft

According to Shah, healthcare.gov fails to employ HttpOnly, which restricts access to cookies stored on a PC, in particular defending them against malicious scripts. The site also fails to employ secure flags for cookies, which prevents cookies from being transmitted in plaintext -- which makes them vulnerable to eavesdropping -- by only transmitting cookies after an HTTPS session has first been established.

"Healthcare.gov uses cookies to maintain user history on the site and [for] user identification," said Shah. Although she doesn't know if the cookies will also save a user's credentials, an attacker could at least retrieve "sensitive information such as ... possible health issues, income level, and marital status," she said, that most people would rather remain private.

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
MarciaNWC
50%
50%
MarciaNWC,
User Rank: Apprentice
10/9/2013 | 6:51:44 PM
re: 5 Obamacare Health Site Security Warnings
Seems like development was rushed, making security less of a priority, which is fairly shocking considering the sensitivity of the data involved.
JEngdahlJ
50%
50%
JEngdahlJ,
User Rank: Apprentice
10/8/2013 | 3:32:29 PM
re: 5 Obamacare Health Site Security Warnings
Communicating healthcare reform: Helping navigate the waters. See: http://www.healthcaretownhall....
Mathew
50%
50%
Mathew,
User Rank: Apprentice
10/8/2013 | 12:11:21 PM
re: 5 Obamacare Health Site Security Warnings
I don't think the lack of availability will pose a security risk. I think any failures will simply result in the site being unavailable.

Still, the domain of load management and load balancing seems pretty circa-late-1990s. Meaning that with proper prep time, all of this should have been ironed out well in advance. But as you noted in your tech critique of the insurance exchanges, owing perhaps to the timelines involved (short) and logic requirements (complex, given the complex law that the site and its workflows must accommodate), obviously too little time has been spent to ensure the site can meet projected demand.

Data quality also sounds like an ongoing challenge, with insurers reporting last week that they had seen few (if any) actual applications, suggesting that the system isn't yet as automated -- and the source data as clean -- as it will need to be.

On the flip side, in this era of agile development, perhaps there are some upsides to the current scenario? The high-profile launch, while frustrating for users, has lit a fire under development teams, and whoever is holding their purse strings. How many federal and state IT projects in the past have too often exceeded their budgets, been "over-redesigned" throughout implementation and as a result faced interminable delays, if ever reaching fruition? But heathcare.gov is now live. The development team must iterate, refine and improve the system to the point where it should have been, prior to being launched.
David F. Carr
50%
50%
David F. Carr,
User Rank: Apprentice
10/7/2013 | 6:31:04 PM
re: 5 Obamacare Health Site Security Warnings
I wonder if there are risks inherent to the sites being overloaded - whether they're likely to fail under stress in a way that reveals private info
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19702
PUBLISHED: 2019-12-10
The modoboa-dmarc plugin 1.1.0 for Modoboa is vulnerable to an XML External Entity Injection (XXE) attack when processing XML data. A remote attacker could exploit this to perform a denial of service against the DMARC reporting functionality, such as by referencing the /dev/random file within XML do...
CVE-2019-19703
PUBLISHED: 2019-12-10
In Ktor through 1.2.6, the client resends data from the HTTP Authorization header to a redirect location.
CVE-2012-1577
PUBLISHED: 2019-12-10
lib/libc/stdlib/random.c in OpenBSD returns 0 when seeded with 0.
CVE-2012-5620
PUBLISHED: 2019-12-10
** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
CVE-2013-1689
PUBLISHED: 2019-12-10
Mozilla Firefox 20.0a1 and earlier allows remote attackers to cause a denial of service (crash), related to event handling with frames.