Blind XPath Injection Attack: A Case Study

Transcription

1 Article can be accessed online at Blind XPath Injection Attack: A Case Study Jyoti Lakhani* Abstract Extensible Mark-up Language (XML) is adopted by different organizations as a data exchange format for web services and internet applications. The XML is much prone to hackers attack. The common hacking technique for XML is XPath injection. The attacker can exploit the XPath to manipulate the database. XPath Injection attack can even bypass the system security and results can be disastrous. In this communication Blind XPath code injection problem is being reviewed using a case study. This article discusses the extent of the problem and few principals for managing and solving XML deployment. Keywords: XML, XPath Injection, Blind XPath Injection 1. Introduction XML (W3C Recommendation, 2000) is a data management tool which is used to transfer data between distributed and heterogeneous systems. XML is a textbased mark up language hence it can be recognized by any platform. XML serves as an intermediate schema between two non-compatible databases. Once stuffed in the XML, the data become completely transparent and highly accessible. Concealing of the data in XML database is not possible (Klien, 2005). XPath (W3C Recommendation, 1999 & W3C Working Draft, 2003) is a language used to refer to parts of an XML document. XPath is a tool to query an XML document with the help of XQuery(W3C Working Draft, 2003) and it can also be used to transform the XML database visualization and representation using XSLT(W3C Recommendation, 1999) (Klien, 2005). XPath query is a query language which is used to traverse and access the XML database. Stuttard (Stuttard 2007) reports that XPath injection attack is the most frequent types of attacks within the Web environment. The communicated problem Blind XPath Injection is a kind of code attack. The hacker injects a code snippet in the XML document to surpass the security banners. Blind Xpath can work even if the attacker is unknown to the XPath of the document. The extent of its danger is that even if the application is written for a limited query, the whole content of the database can be hacked by Blind XPath. 2. XPath Injections XPath queries are used for search requests, login processing, and data retrieval and for other lightweight database tasks (Klien, 2005). An attacker does no need to guess the XPath query upon spotting an XPath Injection in an XPath based application, A few attempts make out the attacker generate a stencil query that can be used for Blind XPath Injection. This code snippet of XPath query can be used to dig out the complete XML document (Klein, 2005). The Blind XPath injection attack can successfully perform using two methods; XPathCrawling and Boolenization of Xpath Query (Klein, 2005). Klein has been discussed the types of XPath injection attacks and its consequences in According to the Klein there are two types of Xpath attacks, XPathCrawling and Boolenization. The author presents possible mechanisms of attacking anxpath query with different samples for each type of attacks. Similar to XPath injection attack is the SQL injection. Comparative work has been done * Assistant Professor, Maharaja Ganga Singh University, Bikaner, Rajasthan, India. jyotilakhanimgsu@gmail.com

2 Blind XPath Injection Attack: A Case Study 31 by Blasco in Blasco provides a brief introduction to XPath injection techniques and portrays various scenarios where possible attacks can completely retrieve the XML document for a given malicious XPath query. (Blasco, 2007) The work also raises security issue in XML databases due to unavailability of access right as opposed to traditional relational databases. Subsequently Groppe in 2009 propose the satisfiability test for an XPath query. Only in 2009, a novel method to detect an XPath injection is proposed by Mitropoulos. Mitropoulos uses the location specific identifiers to validate the executable XPath query by reflecting the call sites within the application. The major flaw of this proposed technique is any change in the source code will require a new training to reassign the identifiers hence it is time consuming and complex. Another work in detecting the XPath injection is by using Aspect Oriented Programming (AOP) where the Web services are instrumented to intercept all XPath commands executed. This technique will generate a whitelist consisting of legitimate workload based on the Web services operation through learning of the XPath queries. After the attack workload has been generated, the technique will be able to detect the XPath injection by comparing both lists (Antunes, 2009). Above of all existing methods, there is still lack of security protection against Blind XPath injection attacks in Web services environment. 3. XPath Attack Figure 1: Indirect Exposure of an XML Document the database to an XML flat file. This XML flat file is a simple text based file which could be exposed to two different types of applications. The internal application named Security Check can direct access the database. The users of this internal application are trusted users of the application. The internal application is protected by the firewall. The external application called login. This application is operated by un-trusted users. The arrows in the figure1 indicate the accessibility of data. A Blind XPath Injection make possible for an attacker to access the entire XML database. Figure 1 demonstrates that internal applications use some data from the database in the form of XML flat files. This extracted data is queried by the user using external applications. It is clearly shown in figure 1 that external application cannot query internal applications directly. This connection is secured by a firewall. In continuation to the above, if there is a XML based application that requires authentication, it might have a table called users with a unique loginid and a password. If the users table in a relational database is fetched in an XML dump, the table will look like figure 2. A SQL query to retrieve a user from the users table can be written as: Query1: SELECT * FROM users WHERE login ID = abc AND password= cba123 In this query the user has to give the loginid and the password as input. If an attacker enters [ or 1=1] in the loginid field and [ or 1=1] in the password, This will always result in a match so that the attacker gains entry to the system. Query2: SELECT * FROM users WHERE loginid = abc AND password= cba123 XPath injection works much the same way. A matching XPath statement to the above SQL query is: Query3: //users/user [loginid/text()= abc and password/ text()= cba123 ] And for bypassing authentication attacker can write the query: *Source: obuji (2006) The figure demonstrates that the data is dumped from Query4: //users/user[loginid/text()= or 1=1 password/text()= or 1=1] and

3 32 International Journal of System and Software Engineering Volume 1 Issue 1 June 2013 There might have a method in application that performs the authentication again using the XML document: Query5: //users/user[loginid/text()= or 1=1 or = and password/text()= or 1=1 or = ] This will logically result in a query that always returns true and will always allow the attacker to gain access (Sen, 2007). 4. Extracting the XML Schema The XPath query in Q4 not only bypasses the authentication procedure, it can also be used to extract information about the XML schema. By-chance if the name of the child node is correctly guessed by the hacker and if the attacker enters the following query: Query6: String (//users[loginid/text()= abc or name(// users/loginid[1]) = LoginID or a=b and password/ text()= ]) Figure 2: Users Table <?xml version= 1.0 encoding= UTF-8?> <users> <firstname>abc</firstname> <lastname>cba</lastname> <loginid>abc</loginid> <password>cba123</password> <firstname>xyz</firstname> <lastname>zyx</lastname> <loginid>xyz</loginid> <password>zyx123</password> <firstname>ijk</firstname> <lastname>kji</lastname> <loginid>ijk</loginid> <password>jki123</password> <firstname>rst</firstname> <lastname>tsr</lastname> <loginid>rst</loginid> <pasword>tsr123</password> </users> By trial and error, the attacker can guess the various other child nodes of the XML document and gather information by seeing if this XPath expression results in a successful authentication. This way a simple code snippet can access an XML document to its full extent (Sen, 2007). This kind of practice oppose to the principle of database security which is onlyauthorized users with legal authentication allowed to access, view and update data (Zhiyong Li, 2011). At the extreme, the hacker will modify database data and in some cases execute database administration operations or system commands (Stuttard 2007). 5. Management of XML Documents XML documents can be managed by applying following principles:- If any application is accessing a part of an XML document then keep in the mind that this entire XML document is indirectly exposed to the application and its users (Obugi, 2006). XML Sorce File for an application does not contain the entire XML database. It should only include the information the application needs for its workings. (Obugi, 2006) This is possible by providing XML based data on need-to-know basis by trimming the XML file. Figure 3: Trimming XML Documents on a Need-to-Know Basis *Source: Obuji (2006) Figure 3 shows the procedure of trimming an XML file. In this scenario, the users still use an XML dump, but no application ever accesses that full document directly. Rather, a separate subset of XML file is accessed for each

4 Figure 4: The XML Pipeline Architecture Blind XPath Injection Attack: A Case Study 33 application on need-to-know basis. This can be done by an automated process called the XML trimmer. This is how the unauthorized information access can be controlled by isolating applications from the original database. Application should be design in such a way that it access XML data through XML pipelines. The application should get data on need to know basis only. (Obugi, 2006) The XML pipeline architecture (figure 4) divides the whole query into smaller parts. The Pipeline architecture maintains the clarity of the flow of all data across XML applications. This clarity allows assess potential threats. 6. Conclusion The XML databases are just simple text files so these are highly transparent. Transparency of XML files is the major cause of the XPath injection attack. This article has given a short overview of XPath and the principles useful for securing XML database centric applications. One type of XPath injection attack is Blind XPath injection which is highlighted in this paper. Xpath is the most frequent types of attacks within the Web environment. XPath injection attack takes place due to the insecurely coded applications. When these applications send update or manipulating queries to a database it is prone to Xpath attack and enabling access to critical data. There are many existing methods to overcome the problem of XPath injection attacks such as strong input validation, parameterized XPath queries and the use of custom error. But these methods are not consistent to prevent XPath injection in Web services. Besides these preventing methods, the programmer should remember the managing principals of XML security. To mitigate the problems of security applications should design in manner that exchange small and controlled chunks of XML data in manageable processing stages. Programmer of XML based application should always apply the security checks. XML based applications should always implement the pipeline architecture when accessing the database using XML Queries and XPath. This reduces the blind spots and makes the application easier to maintain. References 1. Antunes, N., Laranjeiro, N., Vieira, M. & Madeira, H. (2009). Effective Detection of SQL/XPathInjection Vulnerabilities in Web Services. In Services Computing, SCC 09. IEEE International Conference, pp Blasco, J. (2007). Introduction to X-Path Injection Techniques, Hakin9. Conference on IT Underground, Czech Republic, pp Groppe, J. & Groppe, S. (2008). Filtering unsatisfiable X-Path queries. Journal Data & Knowledge Engineering, 64(1), Klein, A. (2005). Blind X-Path Injection. Whitepaper, Watchfire. Retrieved from modsecurity. org/archive/amit/blind-xpath-injection.pdf 5. Li, Z., Shamy, S. M. E. & Galal, T. (2011). A Novell security framework for web application and database. JDCTA: International Journal of Digital Content Technology and its Applications, 5(10), Mitropoulos, D., Karakoidas, V. & Spinellis, D. (2009). Fortifying Applications against XPath

5 34 International Journal of System and Software Engineering Volume 1 Issue 1 June 2013 Injection Attacks. MCIS 2009: 4th Mediterranean Conference on Information Systems, Athens, pp Obugi, U. (2006). IBM, Thinking XML: Manage XML data sets for security, XML Thinking Forum. Retrieved from developerworks/library/x-think37/. 8. Sen, R. (2007). Avoid the dangers of XPath injection, IBM Technical Library. Retrieved from Stuttard, D. & Pinto, M. (2007). The Web Application Hacker s Handbook: Discovering and Exploiting Security Flaws. Wiley, ISBN-10: W3C Recommendation. (2000). Extensible Mark-up Language (XML) 1.0 (2 nd Ed.). W3C Recommendation. 6 October Retrieved from W3C Recommendation. (1999). XML Path Language (XPath) Version W3C Recommendation. 16 November Retrieved from TR/xpath 12. W3C Working Draft. (2003). XML Path Language (XPath) W3C Working Draft. 12 November Retrieved from xpath20/