Vulnerabilities snd web application databases

I write the summary below from the perspective of someone with experience configuring web application and database security as well as investigating security incidents.  Websites are attacked for many reasons. The contents of a database may be the prize, but not always.  Researching and implementing best-practice configurations and monitoring can go a long way to reducing the risk of a website hacking incident.

Context of Web Database Vulnerabilities

Understanding web-application vulnerabilities begins with understanding an attacker’s perspective of the web. Web applications with integrated or supporting database technology have become commonplace due to the Internet (The SANS Institute, 2013). The number and breadth of web applications provide a broad attack surface for activities ranging from reconnaissance to full comprise of information systems and resources. Web applications are also associated with information assets of value such as bank accounts and Social Security numbers (SSNs).

Web applications have a history of deficient security practices. Poor security was systemic and included with developers insufficient coding skills, use of vulnerable PHP code, and lack of understanding about the limitations of vulnerability scanners (Bau, Wang, Bursztein, Mutchler, & Mitchell, 2012).  Further, security testing was not appropriately established part of of the software development lifecycle process (The SANS Institute, 2013; Stuttard & Pinto, 2011). Testing was likely to be limited to business functionality rather than robust.  There were also cases where potential legal liability and limitations due to third-party relationships or cloud-provider restrictions potentially limited testing. The combination of limited testing with minimal examination of security, complex software design, and opportunity for illicit gain contributed to the motives and opportunities for hackers.

Finally, security implementations may contribute to particular vulnerabilities.  When security mechanisms are implemented in web applications, the points of security implementation could also become a point of attack. There are several points of security overlap that include user access, user inputs such as forms, administrative functions, and application and business logic flaws. If interactions between various software code components are not collectively evaluated, then security gaps could move to production without being detected.

Attacker’s Approach to Compromise

Web applications, their related databases, and the information systems that support web applications are open to potential attack due their Internet-facing connectivity. Attackers begin their work with reconnaissance to map systems, ports, protocols, and information resources. Low-hanging fruit such as databases with SQL injection vulnerabilities are easily located and identified for exploitation. Further reconnaissance becomes a process of discovery to learn about the technical intricacies of a particular application and its supporting environment. This deeper exploration provides the opportunity to identify vulnerabilities for possible exploitation. The final phase in the attacker’s work is exploitation. In some cases, exploitation is simply the uploading of malicious malware to an unsecure folder. In other cases, exploitation can be a complex chain of events that begins with gaining foothold within a system in order to perform internal reconnaissance within a network. Public-facing visibility from the Internet plays a critical role throughout the attack reconnaissance, discovery, and exploitation cycle.

Web Database Vulnerabilities

Databases are one form of data repository that store data associated with a web application’s functionality and application logic (Studdard & Pinto, 2011). Most data stores employ a structured format to store data such as relational database or extended markup language (XML) repository. The most common forms of data storage are structured query language (SQL) databases, XML stores, and Lightweight Directory Access Protocol (LDAP), which provides distributed directory information management. Databases may be hosted on the same machine as a web server, which hosts a web application, or on a separate server (Goodrich & Tamassia, 2011).

Data stores employ interpreted scripting languages for creation, modification, and deletion of records as well as for viewing records (The SANS Institute, 2013). Interpretive languages process instructions sequentially as they are encountered, and SQL and XML Path Language (XPath) scripting are both database scripting tools that serve as the main attack vector in database attacks.

SQL injection is the most common form of database attack (The SANS Institute, 2013). SQL injection involves the insertion of additional or malformed code that results in the exfiltration of data, file upload, database system change or other unauthorized modification to a database (Goodrich & Tamassia, 2011). XPath has similar attack vectors as SQL injection (The SANS Institute, 2013). SQL and XPath injection attacks vary by type of database and host file and operating systems. The common thread is the insertion of unauthorized access or modification of a database through SQL or XPath.

Other methods of database attacks involve manipulating the host or applications that support and interact with a data store (Studdard & Pinto, 2011). One example is authentication bypass attacks in which an attacker gains access to system resources outside of the designed and authorized authentication process. If an attacker bypasses authentication for an application or host system account, then a database may be fully accessible without the need to manipulate the database.

Establishing Protection

Web database protections involve the use of layered security to protect the database from threats to external and internal penetrations and manipulation (Studdard & Pinto, 2011). External vulnerabilities include user authentication, session management, and access control.   An internal penetration involves the use of exploits such as SQL injection to manipulate or exfiltrate part or all of a database’s contents.

Authentication. User authentication involves the identification and verification of a user (The SANS Institute, 2013). Authenticated data may be stored in a database, but software code or third-party software libraries are often involved in authentication. Protecting authentication involves securing software code and protecting data from its entry in a web browser through transmission and verification as well as event logging (Studdard & Pinto, 2011). Protecting data involves the use of encryption and validation of user input. Validation may also include the use of specific personal information to prevent attempts at compromising authentication. An example would be challenge questions use in the recovery of a password.

Session Management. Session management is part of the authentication process (Studdard & Pinto, 2011). Each time a user logs into a web application, a session is created. This session may be a point of particular interest to an attacker who wished to hijack the session. To protect sessions, tools such as session token are used to track an individual who logged in from a particular device at a certain time. Databases are important since some databases store session data, and the tables that store session data could contribute to an attacker understanding an organization’s session management. Intercepting weak use tokens for a session could also provide insight on database structure and contents. Securing tokens or using other methods to track user sessions are completed for attack prevention.

Access Control. Access control takes places after authentication is completed. Access controls are important with respect to a database since access controls are intended to restrict the actions of legitimate users, and manipulation of access controls could lead to privilege escalation or other actions that compromise a database (Sandhu & Samarati, 1994).

Handling User Input (The SANS Institute, 2013). User input is an important target for attackers since it provides a potential entry point into a system. From a security perspective, all user input should be treated as untrusted. As user input is transmitted, it should be verified, sanitized, and validated prior to use by code or introduction to a database (Studdard & Pinto, 2011). SQL injection vulnerabilities may result from poorly handled user input.

Protecting the System. Protecting the system and applications that interact with databases is as important as handling input. If an attack is able to upload a file or perform a buffer memory overload, then accessing the database from within an organization may have greater repercussions than attacks such as SQL injection (The SANS Institute, 2013). Basic protections include web application firewalls, folder directory access controls, and physical or logical database segmentation to achieve baseline security.

Data Governance and Management. Many organizations have records and data management groups that focus on data hygiene. These groups inspect and validate the records and data within a database. If there are unusual patterns, then investigations into suspicious activity may take place. This process employs also employs proactive data classification to reduce the risks of wrongfully entered data or attempts to manipulate data (Shaikh, & Sasikumar, 2015). In this capacity, data governance provides an additional layer of data security protection.

References:

Bau, J., Wang, F., Bursztein, E., Mutchler, P., & Mitchell, J. C. (2012). Vulnerability factors in new web applications: Audit tools, developer selection & languages. Stanford, Tech. Rep.

Goodrich, M. T., & Tamassia, R. (2011). Introduction to computer security. Boston: Pearson.

Sandhu, R. S., & Samarati, P. (1994). Access control: principle and practice. IEEE communications magazine, 32(9), 40-48.

Shaikh, R., & Sasikumar, M. (2015). Data Classification for achieving Security in cloud computing. Procedia Computer Science, 45, 493-498.

Stuttard & Pinto. (2011). The Web application hacker’s handbook. Indianapolis, Indiana: Wiley Publishing, Inc.

The SANS Institute. (2013). Security 542: The attacker’s view of the Web. Bethesda, MD: The SANS Institute.

The SANS Institute. (2013). Security 542: Web app pen testing and ethical hacking. Bethesda, MD: The SANS Institute.

Note:

SANS training in web-application security provides a robust introduction with immense depth.  The training materials cover a diversity of tools and best practice web application security measures.