Database Security in Web Applications Database Security in Web Applications

Database Security in Web Applications 1 Database Security in Web Applications Patrick Kruse Department of Computer Science Wake Forest University Spring 2008 Honors Thesis Advised by Dr. Stan Thomas 1 Database Security in Web Applications 2 Abstract Widespread availability of internet access coupled with the increase in number of web applications has led to a surge in the amount of personal data stored online. This data is stored within the database, one of a number of components crucial to the web application’s successful operation and functioning. A wide variety of attacks that can be grouped into the category of “injection attacks” can be used to maliciously attack the database server and database of a web application. These attacks consist of injecting specially formatted data into the application with the hope of corrupting the internal functioning of the database server. A special type of injection attack, known as blind SQL injection, is particularly threatening because it is hard to detect. A number of methods aimed at preventing injection attacks with the aim of increasing database security exist and should be implemented at all costs. 2 Database Security in Web Applications 3 Introduction In the past decade alone, the widespread availability of broadband internet connections coupled with the relatively low cost of internet-capable computers has led to a boom in the number of internet users (CIA, 2008). As entire populations log on to the internet, the amount of physical data stored by web-based applications continues to soar. Internet users interact with and use web applications every day for a wide spectrum of tasks, ranging from online banking to social networking, and everything in between (Cova, M., Felmetsger, V., Vigna, G., 2007). Web applications, by their nature, consist of a number of interconnected components. Each of these components plays a role in the effective and proper functioning of the application as a whole. It is the job of the web designers and developers to ensure that each component is configured properly. Upon proper configuration, these applications are easy to use and infinitely helpful. An improperly configured web-application, however, becomes a security nightmare. An exploitable web-application implies an abundance of personal data accessible from any internet-connected computer, and is of immediate concern not to only the owner of the application, but each user of that application as well. One of the key components of every web application and arguably the most important in terms of security is the web application's database. The database is the heart of any data-driven web application, and must be guarded from numerous types of malicious attacks. Web Application Organization A basic understanding of web application architecture is essential before a discussion on database security within web applications can take place. A high level view of a web application consists of 5 primary parts: the user, the firewall, the web server, the database server, and the actual database. A high level diagram can be observed in figure 1. Figure 1: A high level view of a web application architecture The user of a web application is responsible for the manipulation and insertion of data across the internet and into the web application. For the sake of simplicity, the assumption of a browser-based web application will be made. Static HTML pages are manipulated by the user and the data is submitted via an HTML request into the web application. Data specific to the 3 Database Security in Web Applications user is submitted within this request through the use of HTML forms. After traveling across the internet, the request sent by the client’s browser is first encountered by the web application’s firewall. Assuming the request is legitimate according to the rules of the firewall, the request is passed on to the web server for processing. 4 The primary job of the web server is to dynamically generate and send static HTML pages in response to client requests. When a request is permitted into the web application by the firewall, it is parsed by the web server to determine what type of processing must occur. If a non-dynamic HTML page has been requested, the page is sent back to the client and the transaction completes. A page with dynamic components, such as PHP or ASP code, however, requires further processing. These pages are generated by the web server to create a “customized” static HTML page which is in turn sent back to the client. The dynamic portions of these pages are generated based off user-specific data submitted via HTML forms within the request. Dynamic portions of these pages allow for the creation of web pages containing realtime data, and are the backbone of any data-driven web application. The majority of this dynamic content is stored within databases and must be requested from one of the most important components of a web application, the database server. The job of the database server is to accept requests for data from various components of the web application and retrieve this data from the database. The database itself is managed directly by the database management system, or DBMS, and is not directly accessible. Requests must be sent to the database server, a component of the DBMS, which retrieves and delivers data from the database. These requests are sent according to a certain style and syntax, known as the Structured Query Language, or more commonly by its acronym, SQL. SQL is an extensive language that allows for efficient retrieval of specific data from within the database. In the dynamic component of the web page, SQL queries are created based off of the data contained within the HTML request that was sent from client browsers. These SQL queries are passed to the database server, where the query is parsed and the resulting data is retrieved from within the database. This step in web page creation is very important, and the area in which this discussion is focused. SQL queries created on the fly from user submitted data open a window for security implications based off of maliciously submitted data of various types. Attacks targeting the database server and actual database through malicious SQL queries are collectively known as “injection attacks” (DuBois 2007). Injection Attacks An injection attack is any attempt to subvert the database of a web application by sending it unexpected or unsupported data as input. The most common type of injection attack is SQL injection and results from data containing illegal characters or words being passed directly into a dynamically generated query. This query is in time passed on to the database server where the query is executed. “Unsanitized” data, as it is often referred to, can consist of a number of things. Data containing unescaped illegal characters, such as semicolons or commenting characters, can result in unexpected and dangerous queries. Data that is not type-checked is also considered unsanitized because it can lead to improperly formed and often dangerous queries. If a query is expecting numeric input but instead receives textual input, the faulty input can easily be misinterpreted by the database server as a textual command. This sort of error resulting from 4 Database Security in Web Applications data that has not been properly escaped and type checked is a security vulnerability that must be fixed (Maor & Shulman 2007). It is important to note that injection attacks are different than traditional attacks on the web server. In an injection attack, there is no attempt to gain access of any kind to the server. The goal of an injection attack consists of taking advantage of vulnerabilities within the web application’s use of the database server and database itself. Figure 2 illustrates the location of such a vulnerability within the architecture of a web application. 5 Figure 2: Location of an SQL injection vulnerability within a web application This vulnerability can be used to expose sensitive data that could in turn allow for things like machine access, but at its most basic form, injection attacks are targeted toward the database server and database, not the web server. SQL injection can be used for a number of malicious acts. Most of these acts can be split into three categories: Data destruction, data manipulation, and data extraction. Data destruction consists of manipulating queries to inadvertently delete data from the database. The obvious implications of this type of attack are the immediate and catastrophic removal of some or all of the data within the database. Data manipulation consists of injecting data into queries in such a way that they update data within the database. Manipulation is commonly used maliciously on web applications in which the contents of a database are used to format the various pages. Manipulating the contents of the database can now be used to deface the web application in a number of ways. Data extraction involves injecting data into queries to allow a malicious user to coerce the database into divulging the details of its data to a user who is not necessarily entitled to such data. Data extraction implies problems along the lines of identify theft, data theft, and authentication or security breaches (Gehani 2007). Blind SQL Injection Blind SQL injection differs from traditional SQL injection not by the way in which data in injected, but in the way that data is extracted. Blind SQL injection involves forcing a database server to parse and execute an injected query similar to normal injection attacks. With blind SQL injection, however, the response of the database server is observed in order to make 5 Database Security in Web Applications 6 conclusions about the resulting data inside of the database. Blind SQL injection is applicable to web applications that are vulnerable to SQL injection, but secure enough to not display sensitive data. Conclusions concerning the internal content of the database can be made through a number of techniques, the most popular being so-called “conditional” techniques and time-delay techniques (Maor & Shulman 2007). “Conditional” blind injection attacks consist of injecting data into a query with the intent of forming a conditional query that can be used to test the contents of a database. Queries can be injected with specific data to make them conditional, implying that they will only execute under certain conditions. Assuming a query is injectable, execution of queries containing injected conditionals can be used to make conclusions concerning the internal data of the database. By observing the difference in the behavior of the web application between true and false conditionals, a malicious user can determine the contents of the database by cleverly forming injected queries and testing them. Conclusions about table contents can be made when a “true” response is observed, while further testing can take place when a “false” response is observed. For example, a web application that is susceptible to conditional blind SQL injection will respond differently to the queries illustrated in figure 3. The injected portion of the query has been italicized. Expected Query SELECT * FROM table WHERE id = 5446; Injected Query #1 SELECT * FROM table WHERE id = 5446 AND (1+1)=2; Injected Query #2 SELECT * FROM table WHERE id = 5446 AND (1+1)=3; Figure 3: Example of queries injected with conditional statements Differing behavior between injected query #1 and injected query #2 reveals a blind SQL injection vulnerability. By replacing the numeric conditionals with conditionals relating different columns in the tables of the database, we can make conclusions and effectively extract information regarding the contents of the database (Van den Heetkamp 2006). Time-delay blind SQL injection attacks involve injecting queries with computationally intensive commands and then executing them conditionally. The computationally intensive commands are specifically designed to cause a noticeable, measurable delay. By executing them conditionally, conclusions can be made in terms of how long it takes the web server to respond to the request. Queries can be injected with conditions that execute computationally intensive commands only in certain cases, and a lagging response from a web server implies that the condition being tested is true. In a similar manner to the conditional blind injection attacks, time-delay attacks can be used to deduce the contents of a database. Computationally intensive commands that are commonly used are the SQL benchmark command or any math-intensive computation. An example of a time-delay injection using the benchmark command can be observed in figure 4. Assuming the condition section of the subquery evaluates to true, an 6 Database Security in Web Applications intense benchmark will execute cause the server to slow down. On commodity hardware, this sort of benchmark will produce a delay somewhere around 5 seconds, depending on specific hardware. This is a very specialized attack that must be tailored to each system. Once it is configured correctly, however, it can be run numerous times to enormous amounts of data one character at a time (Alonso 2007). 7 Expected Query SELECT * FROM table WHERE id = 5446; Injected Query SELECT * FROM table WHERE id = 5446 AND 'a' in (SELECT IF(ASCII(SUBSTRING(user,1,1))=ASCII('a'),BENCHMARK(1000000, MD5(char('a'))),NULL) FROM users WHERE id=1); Figure 4: Example of a query with a time-delay based injection The implications of blind SQL attacks share many similarities to normal injection attacks except that, in general, the attacks go undetected unless they are being actively sought out. Blind SQL does not directly pose the threat of data destruction or manipulation because the techniques used in blind attacks serve to massage the data out of the database and not to destroy or change it in any way. Because of this, the threat of data extraction for blind SQL injection is the same as all other injection attacks. What makes blind SQL injection particularly vile is that unless it is being specifically sought out, it is very difficult to detect. This is due to the fact that blind attacks extract data from a database through observations of the web application’s behavior while executing injected queries. The behavior of the web application is not permanently modified, and returns to normal quickly after processing the injected query. The best and somewhat idealistic way to guard against blind SQL injection is to build a system which is not injectable in any way. If blind SQL attacks must be sought out and detected, however, one method that currently exists is to study the database query logs as well as the web server logs to detect anomalous behavior. Because blind SQL injection attacks often take some time to execute, their behavior can sometimes be observed in time to block the attack from completing as well as subsequent attacks. Furthermore, many blind SQL injection attacks are very repetitive, with injected queries being run hundreds, even thousands of times. This sort of traffic stands out once a log file is examined and can be identified and separated from legitimate traffic (Maor & Shulman 2007). Prevention of Injection Attacks Injection attacks of all kinds can be prevented at three different levels, all of which must be considered to produce a secure web application. At the lowest level is query security. The most common and effective way to ensure the security of queries is to use database prepared statements. All injection attacks stem from the same idea of taking an innocent, dynamically generated query and disrupting the logic in order to force the execution of an unintended query. Prepared statements are supplied to the database query engine ahead of time, allowing the engine to precompute the logic. This offers an advantage to web application designers in that if the 7 Database Security in Web Applications logic of a query is precomputed, it cannot be disrupted and used in a malicious way. By using prepared statements, web application designers can, in essence, “hard code” the logic of a query to prevent its misuse. The primary disadvantage of prepared statements is that they are very inflexible. Web applications involving unpredictable, highly dynamic queries often find prepared statements too rigid for effective use. 8 Another important aspect in preventing injection attacks involve properly configured database permissions. Often overlooked, it is crucial that the database be accessible only in ways necessary for the operations of the web application. Database access can be strictly enforced through the proper configuration of database users and their respective permissions. By restricting database users to non-modifying queries, for example, the amount of damage done by an injected query amounts to much less. The database users employed in the web applications should be given as few permissions as possible without impacting the proper functioning of the web application (DuBois 2000). Finally, injection attacks can quite often be successfully halted through properly configured web applications. Proper sanitization and type checking of data is absolutely crucial. All data coming into a web application should be isolated and not trusted until it has been properly type checked and sanitized. Use of unsanitized data is inexcusable and an open window for a plethora of security problems (Converse & Park 2004). Conclusion Malicious attacks on web applications pose a serious threat given the modern, dataintensive society. As billions of people log on, they use web applications for any number of tasks from managing bank accounts organizing their social life. All of these web applications store enormous amounts of data pertaining to its individual users, and much of this data is highly sensitive. Anytime highly sensitive data encounters a web accessible application, it must be assumed that the data will be the target of malicious attacks. As the internet has evolved from static HTML pages to highly dynamic web applications, so have the numbers and varieties of malicious attacks. A wide range of injection attacks, ranging from simple SQL injection to complex, difficult to detect blind SQL injection, have emerged and wreaked havoc on the architecture of these web applications and the lives of their users. As the technology continues to develop, so will the security threats and techniques used by malicious users. As the users of the internet migrate more of their sensitive data into the online environment, it is crucial that security be given the highest regard in the development of web applications. 8 Database Security in Web Applications 9 References Alonso, Chema (2007). Time-Based Blind SQL Injection with Heavy Queries. Microsoft TechNet. Retrieved April 17, 2008 from http://www.microsoft.com/technet/community/columns/secmvp/sv0907.mspx Central Intelligence Agency (2008). World Fact Book. CIA. Retrieved April 15, 2008 from https://www.cia.gov/library/publications/the-world-factbook/index.html Converse, T. & Park, J (2004). PHP5 and MySQL Bible, 531-555. Cova, M., Felmetsger, V., Vigna, G. (2007). Vulnerability Analysis of Web-based Applications. Retrieved April 3, 2008 from www.cs.ucsb.edu/~vigna/publications/2007_cova_felmetsger_vigna_webvuln.pdf DuBois, Paul (2000). MySQL, 392-393, 422-429, 447-450. Gehani, Narain (2007). The Database Book: Principles & Practice using MySQL, 91-133, 279290. Maor, O. & Shulman, A. (2007). Blind SQL Injection. Imperva ADC. Retrieved April 12, 2008 from http://www.imperva.com/resources/adc/blind_sql_server_injection.html Van den Heetkamp, Ronald (2006). SQL Injection cheat sheet. The Hacker Webzine. Retrieved April 12, 2008 from http://www.0x000000.com/?i=14&bin=1110 9