What’s SQL Injection Live Demo
A SQL Injection attack occurs when the user input goes unchecked for validation. The objective is to trick the database system into running malicious code that will reveal sensitive information or otherwise compromise the server.
Typical SQL Injection types
The list of all possible SQL injection types is impossible to define but a good starting point would cover the following possibilities:
• SQL where the where clause has been short-circuited by the addition of a line such as ‘a’=’a’ or 1=1
• SQL where the where clause has been truncated with a comment i.e —
• SQL where the addition of a union has enabled the reading of a second table or view
• Stacking Queries, executing more than one query in one transaction
• SQL where an unintentional SQL statement has been added.
• SQL where an unintentional sub-select has been added.
• SQL where built-in or bespoke package procedures are called where they should not be.
• SQL where access is made to system tables and/or application user and authentication tables.
How to prevent SQL Injection
The problem with SQL injection is, that a user input is used as part of the SQL statement. By using prepared statements you can force the user input to be handled as the content of a parameter (and not as a part of the SQL command). Query parameters help to avoid this risk by separating literal values from the SQL syntax.
Most client APIs (including .NET, Java) support parameterization of queries. This allows embedding the user input as parameters. The parameters are placeholders for user entered value which is replaced at execution time. That way the user cannot inject SQL code as the whole user entry is treated as value for the parameter, not as string appended to the query. parameterization is the best solution for SQL injection attacks.
As most developers already know, a few of other ways to protect against SQL injection is to
• Validate user input to ensure that the input conforms to the business requirements, and ensure that suspicious input is filtered to reduce the possible attack vectors.
• Apply the principals of least privilege to further limit the scope of a successful hack
Why do we still need other tool to help us prevent SQL Injection
• People don’t use parameterized sql, or don’t use it correctly.
• Use dynamic SQL of DDL statements (such as CREATE, DROP, and ALTER)
• Identifiers in SQL statement such as names of columns, tables, schemas, database links, packages, procedures, and functions can’t be parameterized.
• Legacy code, the project is so large that changing all occurrences of bad code can result in massive code rewrite which may not be feasible at the moment
Our solution to detect SQL Injection is precise, effective and scalable by parsing whole input SQL and then reject SQL which tries to do things which you don’t want it to do.
Let take a look at how our tool analyze the SQL to check for some of the above cases that indicate SQL injection.
Case 1, where clause has been short-circuited
Injected SQL: select col1 from table1 where col1 > 1 or 1=1 SQL injected detected: always_true_condition found!
Injected SQL: select col1 from table1 where col1 > 1 and 1=2 SQL injected detected: always_false_condition found!
Case 3, the where clause has been truncated with a comment
Injected SQL: select col1 from table1 where col1 > 1; -- comment at the end of sql statement, maybe a sql injection SQL injected detected: comment_at_the_end_of_statement found!
Case 4, Stacking Queries, Executing more than one query in one transaction
Injected SQL: select col1 from table1 where col1 > 1; update table2 set col1=1 SQL injected detected: stacking_queries found!
Case 5, the addition of a union has enabled the reading of a second table or view
Injected SQL: select col1 from table1 where col1 > 1 union select col2 from table2 SQL injected detected: union_set found!
Case 6, an unintentional SQL statement has been added.
Injected SQL: select col1 from table1 where col1 > 1; drop table t1; SQL injected detected: not_in_allowed_statement found!
How to use this tool in your application
Both Java and C# API of this tool are available, can be easily incorporated into your existing application with less performance impact.
Just validate dynamic SQL query like this:
string sqltext= "SELECT * FROM Users WHERE UserName = '" + username + "' AND UserPassword = '" + password + "'"; SQLInjection.isInjected(sqltext);
We also provide a tool help you to check the potential vulnerability of SQL Server and Oracle stored procedure, this tool can scan all stored procedures inside database automatically hence eliminate SQL injection vulnerabilities.(Please email us(info AT sqlparser.com) if you want to have a try of this tool with subject of “SQL Injection scanner for stored procedure”)
Modify this tool to add you own filter or rule
This anti SQL injection tool comes with source code in Java and C#, so you can customize this tool by adding filter or rule to meet your own requirements, such as
• detect access is made to system tables
• built-in or bespoke package procedures are called where they should not be.
• SQL where an unintentional sub-select has been added
• logging injected SQL for system audit
Need help while using this tool, bug report, request a new feature, need to add a customized validation rule, just email us: info AT sqlparser.com with subject of “SQL Injection tool”.