SQL Injection Report
SQL Injection Report
SQL Injection Report
SQL injection is a type of security attack whereby a malicious user's input is parsed as part of the SQL statement sent to the underlying database. Many variations exist, but the central theme is that the user manipulates knowledge of the query language to alter the database request. The goal of the attack is to query the database in a manner that was not the intent of the application programmer.
Attack Intents
Extracting data, Adding or modifying data, Performing Denial-Of-Service attack, Bypassing authentication, Privilege escalation, etc.
UNION Queries:
SQL allows two queries to be joined and returned as one result set. For example, SELECT col1, col2, col3 FROM table1 UNION SELECT col4, col5, col6 FROM table2 will return one result set consisting of the results of both queries. If the attacker knew the number and types of the columns in the first query, an additional query such as SELECT body, results FROM reports can be appended. If the programmer is not consuming all exceptions, incorrect SQL queries will generate error messages that expose the needed information
Page 1
Using Comments:
SQL supports comments in queries. Most SQL implementations, such as T-SQL and PL/SQL use -- to indicate the start of a comment (although occasionally # is used). By injecting comment symbols, attackers can truncate SQL queries with little effort. For example, SELECT * FROM users WHERE username='greg' AND password='secret' can be altered to SELECT * FROM users WHERE username= 'admin' -- AND password=". By merely supplying admin' --as the username, the query is truncated, eliminating the password clause of the WHERE condition. Since the attacker can truncate the query, the tautology attacks presented earlier can be used without the supplied value being the last part of the query. Thus attackers can create queries such as SELECT * FROM users WHERE username='anything' OR 1=1 -- AND password='irrelevant'. This is guaranteed to log the attacker in as the first record in the users table, often an administrator.
The same SELECT query as in Figure 1, with the user input inserted
This method is not disallowing the program from using tautologies. Eliminating tautologies is not the goal
Let the tautology be there in the user input but find the structure at run time and stop the query to be fed to database engine
This method allows the programmer to include the comments in the SQL statements
Page 3
Implementation details:
The solution was implemented in Java. At the core of this solution is a single static class, SQLGuard, which provides parsing and string building capabilities. The programmer uses this class to dynamically generate, through concatenation, a string representing an SQL statement and incorporating user input. Each SQL string is prepended with SQLGuard.init(), which generates and returns a fresh key. By generating a new key for each database query, we allow for inadvertent discovery of a key, because successive page loads will always have a new key. When a user-provided string, s, is included within an SQL statement, it is first pre- and post-pended with the current key by using SQLGuard.wrap(s). It is imperative that the key not be guessable by an attacker. It uses a sequence of 8 randomly generated ASCII characters (seeded by clock value, thread id, and an application guid). The SQLGuard class has a private method, verify(), which removes the key from the beginning of the query and uses it to identify wrapped user input and build two parse trees. The first tree has unpopulated user tokens for user input. The second tree is the result of parsing the string with these nodes filled in with user input. The two trees are then compared for matching structure. We use a static class and maintain thread identities for each key. A sorted vector is used in the case the container application is multithreaded. We parse the query string using ZQL, a publicly available parser written in Java.
Page 4
Conclusion
This implementation minimizes the effort required by the programmer, as it captures both the intended query and actual query with minimal changes required by the programmer, throwing an exception when appropriate. The future work could be, this solution can also be build on the .NET framework and also in PHP, as well as incorporate automated injection error logging.
References
[1] Using Parse Tree Validation to Prevent SQL Injection Attacks Gregory T. Buehrer, Bruce W. Weide, and Paolo A. G. SivilottiSEM 2005 September 2005 Lisbon, Portugal Copyright 2005 ACM 1595932044/05/09 [2] P.-Y. Gibello. Zql: A java sql parser. In http://www.experlog.com/gibello/zql/, 2002. [3] C. Gould, Z. Su, and P. Devanbu. Static checking of dynamically generated queries in database applications. In Proceedings of the 26th InternationalConference on Software Engineering ( ICSE'04), pages 645{654. IEEE Press, May 2004. [4] Automatic Creation of SQL Injection and Cross-Site Scripting Attacks ICSE09, May 1624, 2009, Vancouver, Canada 978-1-4244-3452-7/09/$25.00 2009 IEEE [5] Combining Static Analysis and Runtime Monitoring to Counter SQLInjection Attacks Copyright 2005 ACM ISBN # 1595931260 [6] A heuristic-based approach for detecting SQL-injection vulnerabilities in Web applications SESS10 , May 2, 2010, Cape Town, South Africa Copyright 2010 ACM 9781-60558-965-7/10/05 ...$10.00. [7] Using Positive Tainting and Syntax-Aware Evaluation to Counter SQL Injection Attacks SIGSOFT06/FSE-14, November 511, 2006, Portland, Oregon, USA. Copyright 2006 ACM 1-59593-468-5/06/0011 [8] SQL-IDS: A Specification-based Approach for SQL-Injection Detection SAC08, March 16-20, 2008, Fortaleza, Cear, Brazil. Copyright 2008 ACM 978-1-59593-753-7/08/0003 $5.00
Page 5