Dangers of XSS Attacks at Healthcare Organizations
by Sarah Harvey / October 30th, 2019
In October 2019, Citizen Times reported that Mission Health, North Carolina’s sixth-largest health system and HCA Healthcare’s North Carolina Division, had disclosed a data breach caused by a cross-site scripting (XSS) attack.
Cross-site scripting (XSS) vulnerabilities rank among OWASP’s top 10 web application security risks. XXS occurs when a web application doesn’t properly sanitize user input and their input (such as malicious code) is either reflected or stored on the returned page. The best way to combat the dangers of XSS vulnerabilities is to perform code review before the application goes into production.
This attack, which injected malicious scripts into Mission Health’s e-commerce web application, wasn’t found for three years. Fortunately, the e-commerce site didn’t impact any PHI, but three years’ worth of names, addresses, payment card numbers, expiration dates, and CVV codes were sent to unauthorized individuals.
Can you imagine if this XSS attack targeted a web application that touched PHI? Could code review have found this XSS flaw? Would penetration testing have helped? This data breach is just one more example of the added precautions healthcare organizations must take to identify all areas of risk and implement cybersecurity best practices, even if they have to go beyond HIPAA requirements.
Cybersecurity in Healthcare
The amount of data breaches that occur within healthcare prove it to be an industry that isn’t keeping up with the cybersecurity threat landscape. According to IBM’s 2019 Cost of a Data Breach Report, the healthcare industry has the most expensive data breaches – the average totaling $6.45 million.
What makes data breaches even more expensive? Time. The time it takes to find the breach and the time it takes to contain and respond to it. IBM reports that, on average, it takes organizations 206 days to identify a data breach and 73 days to contain that breach.
That means when a data breach occurs, it will take the organization about nine months just to find and stop it. Unfortunately for Mission Health, the time it took them to find the injected malicious scripts was about three years – much higher than average.
Perform Code Review to Find Cross-Site Scripting Flaws
Cross-site scripting occurs when a web application doesn’t properly sanitize user input and their input (such as malicious code) is either reflected or stored on the returned page. In Mission Health’s case, it was stored – which can have a severe impact. Web applications are one of the most common attack surfaces for data breaches, and OWASP has determined the XSS flaws are among the 10 most critical security risks to web applications.
It’s extremely difficult to find and remove XSS flaws from a web application, but OWASP says:
“The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output.”
Code review is a tedious job, but someone needs to do it so that XSS flaws or injected malicious scripts don’t go unnoticed for three years.
Part of thorough code review is testing against OWASP’s XSS prevention rules:
- Never Insert Untrusted Data Except in Allowed Locations
- HTML Escape Before Inserting Untrusted Data into HTML Element Content
- Attribute Escape Before Inserting Untrusted Data into HTML Common Attributes
- JavaScript Escape Before Inserting Untrusted Data into JavaScript Data Values
- HTML escape JSON values in an HTML context and read the data with JSON.parse
- CSS Escape And Strictly Validate Before Inserting Untrusted Data into HTML Style Property Values
- URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
- Sanitize HTML Markup with a Library Designed for the Job
- Avoid JavaScript URLs
- Prevent DOM-based XSS
- Use HTTPOnly cookie flag
- Implement Content Security Policy
- Use an Auto-Escaping Template System
- Use the X-XSS-Protection Response Header
- Properly use modern JS frameworks like Angular (2+) or ReactJS
Web Application Penetration Testing
Once code review is performed, a web application penetration test should also take place. The goal of the penetration test is for no additional web application vulnerabilities to be discovered. If there are, that means the code review wasn’t thorough enough – but penetration testing is valuable for validating this.
Web applications can be problematic for many security analysts who don’t have the experience to be testing them – especially if it’s done in conjunction with code review. We often see other firms blindly assign an analyst to a web application project, but without the proper knowledge and expertise, a penetration tester can miss important findings within the web application. That’s why web application penetration testing methods at KirkpatrickPrice include the following, plus more:
- Forced Browsing
- Session Management
- Cookie Manipulation
- Source Code Disclosure
- Response Splitting
- File Upload/Download Attacks
- URL Manipulation
- Injection Attacks for HTML, SQL, XML, SOAP, XPATH, LDAP, Command
- XSS
At KirkpatrickPrice, we also take a hybrid approach to code review that includes both automation and manual assessment in order to find any vulnerability that, if discovered, could be abused. Our team of highly skilled penetration testers have the expertise to understand the complexities of your code.
If you want to avoid a data breach due to unnoticed, cross-site scripting flaws like the one at Mission Health, contact us today.
More Penetration Testing Resources
Guide to 7 Types of Penetration Tests
Think Like a Hacker: Common Vulnerabilities Found in Web Applications
