Protecting Database Centric Web Services Against ...

Protecting Database Centric Web Services Against SQL/XPath Injection Attacks Nuno Laranjeiro, Marco Vieira, Henrique Madeira CISUC, Department of Informatics Engineering University of Coimbra, Portugal {cnl, mvieira, henrique}@dei.uc.pt

Abstract. Web services represent a powerful interface for back-end database systems and are increasingly being used in business critical applications. However, field studies show that a large number of web services are deployed with security flaws (e.g., having SQL Injection vulnerabilities). Although several techniques for the identification of security vulnerabilities have been proposed, developing non-vulnerable web services is still a difficult task. In fact, securityrelated concerns are hard to apply as they involve adding complexity to already complex code. This paper proposes an approach to secure web services against SQL and XPath Injection attacks, by transparently detecting and aborting service invocations that try to take advantage of potential vulnerabilities. Our mechanism was applied to secure several web services specified by the TPC-App benchmark, showing to be 100% effective in stopping attacks, non-intrusive and very easy to use. Keywords: Web services, vulnerabilities, security attacks, SQL Injection, XPath Injection, code instrumentation.

1 Introduction Web services are now widely used to support many businesses, linking suppliers and clients in sectors such as banking and financial services, transportation, or automotive manufacturing, among others. Web services are self-describing components that can be used by other software in a platform-independent manner, and are supported by standard protocols such as SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery, and Integration) [1]. In a service-based environment, providers offer a set of services that frequently access a back-end database and can be explored and used by service consumers. The web services technology provides a clear interface for consumers, and this is frequently used to enable the aggregation of services in compositions [2], where a security failure in a component may compromise the whole composition. A recent McKinsey report indicates web services and SOA as one of the most important trends in modern software development [10]. However, the wide use and exposure of web services results in any existing security vulnerability being most probably uncovered and exploited by hackers. In fact, command injection attacks (e.g., SQL or XPath injection) are frequent types of attacks in the web environment

[11]. These attacks take advantage of improperly coded applications to change queries sent to a database, enabling, for instance, access to critical data. Vulnerabilities allowing SQL/XPath injection attacks are particularly relevant in web services [15], as their exposure is high and they frequently use a data persistence solution [14] based either in a traditional relational database or in a XML database. Currently major database vendors and several open-source efforts provide XML databases (e.g., Oracle XML DB, SQL Server 2008, Apache Xindice, etc) and, frequently, the access to this type of databases uses XPath expressions. While the goal of XPath Injection is to maliciously explore any existing vulnerabilities in XPath expressions used by an application (for instance to access an XML database), SQL Injection tries to change the SQL statements in a similar manner [11]. Although web services are increasingly being used in complex business-critical systems, current development support tools do not provide practical ways to protect applications against security attacks. In this paper, we present a phased approach that is able to: 1) characterize the web service in terms of security vulnerabilities; 2) learn the profile of regular client requests by transforming requests into invariant statements; 3) protect web service applications from SQL/XPath injection attacks by matching incoming requests with the valid set of codes previously learned. Regard that this work focuses on source code vulnerabilities and not any specific security mechanisms, such as authentication or data encryption. A common way to remove SQL/XPath Injection vulnerabilities is to separate the query structure from the input data by using parameterized queries (e.g. prepared statements or parameterized Xpath expressions). In [12] an approach for replacing the SQL statements by secure prepared statements is described. Code inspection and static analysis were used to disclose code prone to SQL injection, which was then replaced by generated secure code. An approach for converting SQL statements into prepared statements is presented in [13]. However, the conversion algorithms are limited and need to be improved to reduce the large number of unhandled cases. AMNESIA (Analysis and Monitoring for NEutralizing SQL-Injection Attacks) [4] is a tool that uses a model-based approach designed to detect SQL injection attacks, and combines static analysis and runtime monitoring. Static analysis is used to build a model of the legitimate queries that an application can generate. At runtime, when a query that violates the model is detected, it is classified as an attack and is prevented from accessing the database. Our approach learns the profile of legitimate queries at runtime, which may represent a richer, more realistic learning profile, overcoming the intrinsic limitations of static analysis (e.g., requiring access to source code). The proposed approach is extremely effective, has a quite low overhead, and does not require any access to the source code of the application. Instead, we use bytecode instrumentation for transparently performing the necessary modifications to protect the target service. To show the effectiveness of our approach we have used two implementations of the web services specified by the TPC-App performance benchmark. A large number of security problems have been disclosed and fully corrected, showing that our approach is effective and a powerful tool for developers and system administrators. The structure of the paper is as follows. Next section presents the technique for fixing security problems and Section 3 presents the experimental evaluation. Section 4 concludes the paper.

2 Security Improvement Approach To perform SQL Injection the attacker exploits an unchecked input in order to modify the structure of a SQL command [11]. Usually, the attacker starts by adding an extra condition in the „where‟ clause of a SQL command to gain a privileged access. Then the attacker executes a SQL command returning valuable information (typically using a union clause with the malicious select), disrupting the database by performing inserts, deletes or updates. Regarding XPath, the attack approach is basically the same and only the expression syntax differs. This way, our proposal for identifying potential SQL and XPath injection attacks is based on anomaly detection, which consists of searching for deviations from an historical (learned) profile of good commands, and includes three major phases: 1. Service assessment – Consists of using penetration testing, automated static code analysis, or human code inspection to disclose SQL/XPath Injection vulnerabilities and thus characterize the service in terms of these vulnerabilities. 2. Statement learning – The goal is to identify the valid set of valid SQL statements or XPath expressions. It is composed of two steps: 2.1. Workload generation, execution, and measurement. 2.2. Service instrumentation to learn valid SQL statements and XPath expressions used by the application. 3. Service protection – Consists of instrumenting the service to provide protection against SQL/XPath Injection attacks. Afterwards, the developer may revisit phase 1 to verify if the previously detected vulnerabilities were effectively protected. 2.1 Service Assessment The goal of this first phase is to assess the security of the web service application in terms of SQL/XPath injection vulnerabilities. This initial characterization phase is optional, as the developer may simply wish to apply the security mechanism as a regular attack barrier, without searching the service for potential vulnerabilities. Any of the following alternatives can be used for vulnerabilities detection: penetration testing (by using scanners or fuzzers) [11]; static code analysis [9] (a developer can easily use tools such as FindBugs [5]); or, in more difficult cases (or in cases where a high degree of confidence is needed), human code inspections by security assurance teams [3]. The outcome of this phase is essentially a set of SQL/XPath injection vulnerabilities in the service code. This information can be used later to verify the effectiveness of the proposed protection scheme by re-running this phase over the protected service. 2.2 Statement Learning This phase includes 2 steps. The first step in this phase consists of generating and executing a workload, which is essentially inspecting the service description document, the WSDL file. This XML file is automatically processed to obtain the list of operations, parameters and associated data types and domains. In this context, we use

a language, named „Extended Domain Expression Language – EDEL‟, that enables web services to fully express their operations domains (including complex parameter domains dependencies) [8]. EDEL can be used to create workloads that respect the operations‟ domains, hence greatly increasing their coverage. After having collected the necessary information, the workload generation is conducted in an automatable way, as proposed in [8]. In summary, the procedure consists of generating a set of XML objects, which are the service inputs (created in compliance with the WSDL file) and integrating them into unit tests in an automatable way. Our goal is to exercise as many source code points as possible (ideally, the complete set of data access SQL/XPath statements present in the code). The final step consists of executing the workload and using a test coverage analysis tool, such as Cobertura ( http://cobertura.sourceforge.net/), to get a metric of the code coverage. If the developer is not satisfied with the coverage then more service calls are required. The second step consist of learning the SQL/XPath commands profile. We start by exercising the web service by executing the generated workload. This enables us to automatically identify all the locations in the web service code where the SQL and XPath commands are executed. This is achieved by using AOP (Aspect Oriented Programming) [6] to intercept all the calls to a set of method signatures that correspond to well-known APIs for executing SQL commands (e.g., Java‟s JDBC API, the Spring Framework JDBC API, etc.) and evaluating XPath expressions (e.g., Java‟s JAXP API). Besides this set of well-known APIs, virtually any API can be easily added to the learning mechanism, as the only requirement is to know the full signature of the method to be intercepted. At runtime, each data access call is intercepted and delivered to a dispatcher that determines if the application is in learning or protection mode. During learning, SQL and XPath commands are parsed in order to remove the data variant part (if any) and a hash code is generated to uniquely identify each command. In other words, the information used does not represent the exact command text, since commands may differ slightly in different executions, while keeping the same structure. For example, in the SQL command “SELECT * from EMP where job like 'CLERK' and SAL >1000”, the job and the salary in the select criteria (job like ? and sal > ?) depend on the user‟s choices. This way, instead of considering the full command text, we just represent the invariant part of it. After removing the variant part of each command it is possible to calculate the command signature using a hash algorithm. We associate each hash with a code entry point (provided that the code being tested was compiled with code line information, which is generally the case). 2.3 Service Protection Service protection at runtime (i.e., after deployment) consists in performing one security check per each data access command executed. All SQL and XPath commands are intercepted and hashed. The request flow is very similar to the learning phase, but obviously, the calculated hash codes are not added to the learned command set. Instead, they are compared to the hash values of the learned valid commands for the code point at which the command was submitted. In practice, the matching process consists in looking up the current source code

origin and getting the list of hash codes of the valid (learned) commands for that point. This list (generally quite small) is then searched for an element that exactly matches the hash of the command that is being executed. Execution is allowed to proceed if a match is found. Otherwise, a security exception (the unqualified name for this exception is SecurityRuntimeException) is thrown and, in this way, code execution is kept from proceeding, which prevents the potential attack. If the source code origin is not found in the lookup process, code execution is also kept from proceeding in a similar manner (in this case, a different exception is thrown – CodePointNotTrainedRuntimeException). This case strongly indicates that the learning phase is incomplete (test coverage was not good enough) and that an extended workload is probably required. To verify if the security mechanism is working properly the web service should be re-assessed using a security analysis approach (similar to phase 1). The goal is to check if any of the initially identified vulnerabilities still exist and the expectation is that our mechanism stops any injection attempts by raising the appropriate security exception. If a security vulnerability is detected it means that the workload coverage was not good enough and that the learning phase is incomplete. In this case, the workload should be extended and the learning process repeated. Finally, the developer may want to re-execute the original workload to verify if the service behavior remains correct. Problem indicators include responses outside the expected domains. For certain services, responses that are different from those obtained during the first workload execution are also problem indicators.

3 Experimental Evaluation In this section we present the experimental evaluation performed over an initial Java prototype tool (available at [7]). To demonstrate our approach we have used the following subset of the web services specified by the standard TPC-App [14] performance benchmark: Change Payment Method, New Customer, New Product, and Product Detail. TPC-App is a performance benchmark for web services and application servers that is widely accepted as representative of real environments. Two versions of each service (versions A and B) were created by independent programmers, and the setup consisted of two nodes (client and server) that were deployed on two machines connected over an isolated Fast Ethernet network. The first phase of the experimental evaluation consisted of performing a services assessment to try to identify potential vulnerabilities. Initially, we opted to use automated tools (vulnerability scanners and static code analyzers), however, due to the poor results obtained we decided to perform a code inspection by a team of security experts with different experience backgrounds. Table 1 summarizes the results. All detected vulnerabilities correspond entirely to SQL injection issues, as the TPC-App specification does not include any XPath usage. However, the assessment approach is essentially the same, as the main difference resides on the syntax of each language. As discussed below, FindBugs, the static analyzer used, was unable to provide individual results per service.

Table 1. Vulnerabilities detected by the different methods. Service

Scanner

ChangePaymentMethod

A 0

NewCustomer NewProducts ProductDetail

1+1 0 0

B

1

0 (3 FP) 0 (3 FP) 0 0

FindBugs A B

Code Inspection A B 2 (2 FP) 0

2

19 (1 FP) 1 (1 FP) 0

0

0 0 0

We used a well-known commercial vulnerability scanner that was able to identify 2 critical vulnerabilities in version A. Both were manually checked and in fact corresponded to SQL Injection vulnerabilities (although one was originally identified by the scanner as a database error). The scanner also indicated 6 vulnerabilities in version B. An important aspect is that version B was using SQL prepared statements (with exception of one statement that, however, does not add any security concern as it is a static SQL command). As prepared statements are the most powerful way of preventing SQL Injection, we were expecting no issues in this version. Anyway, we decided to examine the scanner responses and the code of version B. We found that the reported errors indicated in all these cases a „value to large for column‟ error message. However, even if a smaller attack expression had been used, it would still pose absolutely no threat as the prepared statement engine escapes offending characters like („). As vulnerability scanners are known to present poor results in this kind of environments [15] we decided to use also a well known static code analysis tool (FindBugs) for disclosing SQL Injection vulnerabilities. As we can see in Table 1, FindBugs was able to mark 2 vulnerabilities for version A, and none for version B as expected. Considering version A, the developer created a set of methods for database access and FindBugs marked the last point of the source code where a non constant string was passed to an execute SQL method. We then analyzed the database access methods to try to distribute the vulnerabilities per service, which was not possible, as some services did use the database methods in a vulnerable way, while others did not. To obtain more accurate results we asked a team of security experts to disclose SQL Injection Vulnerabilities in the source code by executing a thorough code inspection and penetration tests. The security analysis team was composed of 5 elements. Three of these elements are developers with more than 2 years of experience on developing database centric business critical web applications in Java. The remaining two are security researchers, one junior (one year of experience) and one senior (four years working on security related topics). Table 1 presents the summary of the vulnerabilities detected by the team (results represent the union of the vulnerabilities detected by each team member). One vulnerability was counted per each web service input parameter used in a given SQL statement in a vulnerable way. It is important to mention that we double-checked the vulnerabilities pointed out by each participant (under the form of an example service request) to discard false-positives. As we can see, 3 of the services were vulnerable in version A, and one in particular had 19 security flaws. This large number is due to a large number of user input parameters, being used in more than one SQL statement throughout the code. As ex1 FP: False positives.

pected, Version B presented no security vulnerabilities. For the second phase (statement learning) we analyzed the WSDL and XML schema (XSD) of each web service and, for each input and output parameter, we manually extended the service definitions to include domain restrictions while fully respecting the TPC-App specification. EDEL [8] was applied to express the final domains. The workload was defined based on a set of web service requests (a total of 5 requests for the 4 services). Before continuing we analyzed the coverage using Cobertura, and found out that, the coverage was in general above 80% (except in one case), a value accepted as representative by the developers. The workload was then applied to exercise each TPC-App version in order to learn the expected SQL commands. After the learning process, we manually checked whether all possible SQL commands executed by the service application were correctly learned by our mechanism, and that was effectively the case. Note that, the learning process is quite important in our approach and is directly influenced by the coverage of the workload used. If there were commands not learned we would have to increase the size (and coverage) of the workload. After this, we proceeded to the third phase by configuring our mechanism to enter the protective state and detect maliciously modified commands, thus improving security. The vulnerability scanner was then used to re-test all services for security vulnerabilities. The results were a total zero disclosed SQL/XPath injection vulnerabilities for all services. All new malicious requests were indeed stopped, preventing any further service execution and possible security consequences. Security tests over version B presented the same initial erroneous results discussed before, so for our purposes the total sum of security issues is zero. Due to the instrumentation technique we were using, we did not re-run FindBugs, as static analysis is not able to detect that our protection mechanism blocks particular data access statement executions. So, we replayed all malicious requests crafted by our code inspection participants. All attempts to inject SQL code were again aborted. To verify if the security improvement mechanisms changed the services‟ functionality we re-ran the workload for all three versions. The web services responses were analyzed for deviations from the valid output domains. No problem was identified, providing a strong indicator that we did not change the application‟s normal behavior. Finally, we executed a test to assess the performance impact related to executing the security system. As we were expecting small values for the security improvement, we tested the worst case scenario found in the services and executed 100000 invocations using that worst-case scenario. Our mechanism took on average 0,052 ms (± 0,029) to execute, less than 0,3% of the total time for the fastest executing service. In summary, our learning mechanism was able to stop all security attacks with a negligible overhead. This is a very significant result, as besides effectively securing the target application, it implied absolutely no extra-effort from the developers that implemented the original services.

4 Conclusion Previous works on web application security have shown that SQL/XPath Injection

attacks are extremely relevant in web service applications. This paper presents an approach for improving web services security. The proposed approach consists of learning the profile of valid data access statements (SQL and XPath) and using this profile to later prevent the execution of malicious client requests. The approach was illustrated using two different TPC-App implementations. Various security issues were disclosed and corrected without additional development effort. In fact, while introducing an extremely low performance overhead, our approach proved to be 100% effective, as it was able to abort all attacks attempted in our experiments. During the whole experimental process, no extra complexity was added to the source code. In fact, as source code is not needed, the mechanism can also be used to easily protect legacy services, which would otherwise require a difficult to implement and hard to maintain procedure. These facts make it an extremely useful tool for developers and service administrators.

References 1. Curbera, F. et al.: Unraveling the Web services web: an introduction to SOAP, WSDL, and UDDI. Internet Computing, IEEE, vol. 6, pp. 86-93 (2002) 2. Erl, T.: Service-Oriented Architecture: Concepts, Technology, and Design, Prentice Hall Professional Technical Reference (2005) 3. Fagan, M.: Design and code inspections to reduce errors in program development. Software pioneers: contributions to software engineering, Springer-Verlag, Inc., pp. 575-607 (2002) 4. Halfond, W., Orso, A.: Preventing SQL injection attacks using AMNESIA. 28th international conference on Software engineering, Shanghai, China: ACM, pp. 795-798: 2006 5. Hovemeyer, D., Pugh, W.: Finding bugs is easy. ACM SIGPLAN Notices, vol. 39 (2004) 6. Kiczales, G. et al.: Aspect-Oriented Programming. 11th European Conf. on Object-oriented Programming (1997) 7. Laranjeiro, N., Vieira, M., Madeira, H.: EDEL and Security Improvement for Web Services. http://eden.dei.uc.pt/~cnl/papers/edel-security-tool.zip (2009) 8. Laranjeiro, N., Vieira, M, Madeira, H..: Improving Web Services Robustness. International Conference on Web Services (ICWS), Los Angeles, USA: IEEE Computer Society (2009) 9. Livshits, V., Lam, M.: Finding security vulnerabilities in java applications with static analysis. Proceedings of the 14th conference on USENIX Security Symposium - Volume 14, Baltimore, MD: USENIX Association, pp. 18-18 (2005) 10. McKinsey&Company: Enterprise Software Customer Survey (2008) 11. Stuttard, D., Pinto, M.: The Web Application Hacker's Handbook: Discovering and Exploiting Security Flaws. Wiley, ISBN-10: 0470170778, (2007) 12. Thomas, S., Williams, L., Xie, T.: On automated prepared statement generation to remove SQL injection vulnerabilities. Information and Software Technology, v. 51, pp. 589-598 (2009) 13. Thomas, S., Williams, L.: “Using Automated Fix Generation to Secure SQL Statements,” Third International Workshop on Software Engineering for Secure Systems (2007) 14. Transaction Processing Performance Council: TPC BenchmarkTM App (Application Server) Standard Specification, Version 1.1, http://www.tpc.org/tpc_app/ (2005) 15. Vieira, M., Antunes, N., Madeira, H.: Using Web Security Scanners to Detect Vulnerabilities in Web Services. Intl. Conf. on Dependable Systems and Networks, Estoril, Lisbon (2009)