Cyber Threats and Vulnerabilities of the iTrust Database

Introduction

In the contemporary business environment, private and public organizations are increasingly using database applications to store employee and customer records. Similar to private organizations that produce goods and services, a growing number of healthcare organizations are also taking advantage of the associated benefits of databases to store employee and patient records (Goodrich & Tamassia, 2011). While there are different types of database applications tailored to serve different industries, the iTrust database has been developed specifically for the healthcare industry. iTrust is a cloud-based healthcare database application that assists medical providers in storing and managing the medical records of patients and health providers.

Similar to a traditional database that contains a number of tables to store medical records, iTrust also maintains tables for that purpose. It additionally serves as a patient-centric application used to maintain an EHR (Electronic Health Record) that combines medical information from different sources, assisting in presenting the complete history of patient records. Despite the benefits that iTrust provides to healthcare organizations, it faces different security risks from web spoofing, insider threats, and coding errors leading to SQL injections (Anderson, 2008).

The objective of this paper is to analyze and assess the security vulnerabilities and threats of the iTrust database application. Specifically, the paper identifies Cross-Site Scripting, SQL injection, session hijacking, response splitting, and natural disasters as the primary threats facing the iTrust database application.

Response splitting is an HTTP header injection vulnerability that can be used to create Cross-Site Scripting attacks against the iTrust database. In other words, response splitting is a type of iTrust database vulnerability that allows an attacker to inject custom strings into web HTTP headers. The attacker can combine response splitting with other attack vectors to steal session data, cookies, and other sensitive information. Response splitting can also be used to intercept a web server and cause persistent defacement of the browser (Sfetcu, 2014).

XSS (Cross-Site Scripting) is a type of iTrust database vulnerability that enables attackers to inject client-side scripts into a web application. XSS allows an attacker to inject code that appears trustworthy and tricks the user into clicking it to perform operations or obtain a copy of a cookie. The motive behind XSS vulnerabilities is to bypass access controls, letting attackers penetrate database applications. In the United States, XSS accounts for approximately 84% of iTrust database vulnerabilities, and the effects can range from minor security risks to significant security breaches depending on the sensitivity of the data involved.

The following example reveals the strategies an attacker can employ to gain access to a Patient ID (pid) using XSS:

Analysis and Assessment of iTrust Security Threats

<% String pid = request.getParameter("pid"); %>
Patient ID: <%= pid %>

The above code can cause a problem in the system because it can be presented as a malicious URL. Social engineering tricks can then be used to lure victims into clicking the malicious URL.

Session hijacking is an example of an iTrust vulnerability that involves cookie hijacking to exploit a valid computer session. Typically, the attacker uses session hijacking to gain unauthorized access to services or sensitive information in the database system. An attacker can use session hijacking to authenticate against a remote server in order to access saved cookies. Session fixation is one method of session hijacking in which an attacker sends an email link containing a particular session ID and waits for the user to log in to collect information. The attacker can also use session side-jacking, employing packet sniffing to penetrate network traffic between two or more parties and steal sensitive information. This strategy allows an attacker to intercept data submitted to the server. Additionally, an attacker can use malware to penetrate the iTrust database and steal cookie files without the knowledge of users.

"A SQL injection attack is performed when a user exploits a lack of input validation to force unintended system behavior by altering the logical structure of a SQL statement with special characters" (Smith, Shin, & Williams, 2008, p. 51). SQL injection vulnerabilities occur when there is no input validation in place to prevent them. The SQL injection attack can destroy the iTrust database because the attacker can inject SQL commands via web page input to alter SQL statements and compromise the security protocols of the database. A malicious input in the iTrust database that can lead to SQL injection is as follows:

Patient ID input: 108 or 1=1

Server result:
SELECT * FROM Patients WHERE PatientId = 108 or 1=1

This SQL is effectively the same as:
SELECT PatientId, Password, Name FROM Patients WHERE PatientId = 108 or 1=1

A skilled attacker can gain access to all patient names and passwords in the database simply by inserting 108 or 1=1 into the input field.

Another example of SQL injection is as follows:

string query = "SELECT patient_account FROM patient_data WHERE user_name = "
+ request.getParameter("patientName");
try {
    Data data = connection.createData( ... );
    ResultSet results = data.executeQuery( query );

Natural disasters such as flooding, landslides, tornadoes, hurricanes, and volcanic eruptions can cause immense damage to database systems and consequently lead to loss of data. If an organization stores all of its data in a central database without implementing an appropriate backup technique, a disaster can result in the loss of all data, bringing business operations to a standstill. This can lead to the loss of customers, damage to reputation, and significant financial loss.

When a natural disaster has led to a security breach or data loss, an organization is required to implement a recovery plan to recover the lost data. However, the time and costs associated with recovery can be challenging if planning was not completed before the disaster. During the recovery process, the affected organization may not recover all data if a recovery plan was not integrated into the iTrust database management strategy.

After a natural disaster, an organization is required to recover data from cold, warm, and hot sites. Hot sites are servers and live sites running in parallel in the event of a disaster. These are the most critical sites for an organization's business operations. A warm site allows pre-installation of hardware and pre-configuration of bandwidth to restore data for business operations. Cold sites include network connectivity centers and data centers. However, business operations can be brought to a standstill if cold, warm, and hot sites are located in the same geographical area as the iTrust database during a natural disaster.

Disgruntled or otherwise malicious employees can cause significant damage to the iTrust database application. An employee within the organization may steal sensitive information from the database for monetary gain or other motives.

A strategy to address the threats from response splitting is to perform context-sensitive encoding. The benefit of context encoding is to improve bug reporting. A bug is an error in system development, and an attacker can exploit bugs to penetrate a database and steal sensitive information. Context encoding therefore assists in detecting bugs and improving the reporting process. Context-sensitive encoding is also important in program optimization (Bidgoli, 2006).

The primary defense against SQL injection is the use of parameterized SQL queries. Parameterized queries prevent an attacker from changing the intent of the queries in the database. Additionally, a developer can blacklist characters or words that could be used for SQL input to prevent SQL injection attacks. An example of a parameterized SQL statement is as follows:

INSERT INTO PATIENT (name, cost) VALUES (?, ?)

The above statement is immune to SQL injection. Another example is:

Conclusion

Smith, B., Shin, Y., & Williams, L. (2008). Proposing SQL statement coverage metrics. Proceedings of the 4th International Workshop on Software Engineering for Secure Systems, 49–56.

Yadav, K., & Srinivasan, A. (2010). iTrust: An integrated trust framework for wireless sensor networks. Proceedings of the 2010 ACM Symposium on Applied Computing, 1466–1471.