{"id":802,"date":"2011-03-06T10:08:02","date_gmt":"2011-03-06T15:08:02","guid":{"rendered":"http:\/\/www.dpriver.com\/blog\/?page_id=802"},"modified":"2015-05-27T22:07:36","modified_gmt":"2015-05-28T03:07:36","slug":"anti-sql-injection-tool","status":"publish","type":"page","link":"https:\/\/www.dpriver.com\/blog\/anti-sql-injection-tool\/","title":{"rendered":"Anti SQL Injection Tool"},"content":{"rendered":"

### What’s SQL Injection Live Demo<\/a><\/h3>\n

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.
\n<\/p>\n

### Typical SQL Injection types<\/h3>\n

The list of all possible SQL injection types is impossible to define but a good starting point would cover the following possibilities:
\n\u2022\tSQL where the where clause has been short-circuited by the addition of a line such as ‘a’=’a’ or 1=1
\n\u2022\tSQL where the where clause has been truncated with a comment i.e —
\n\u2022\tSQL where the addition of a union has enabled the reading of a second table or view
\n\u2022\tStacking Queries, executing more than one query in one transaction
\n\u2022\tSQL where an unintentional SQL statement has been added.
\n\u2022\tSQL where an unintentional sub-select has been added.
\n\u2022\tSQL where built-in or bespoke package procedures are called where they should not be.
\n\u2022\tSQL where access is made to system tables and\/or application user and authentication tables.<\/p>\n

### How to prevent SQL Injection<\/h3>\n

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.<\/p>\n

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.<\/strong><\/p>\n

As most developers already know, a few of other ways to protect against SQL injection is to
\n\u2022\tValidate 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.
\n\u2022\tApply the principals of least privilege to further limit the scope of a successful hack <\/p>\n

### Why do we still need other tool to help us prevent SQL Injection<\/h3>\n

\u2022\tPeople don’t use parameterized sql, or don’t use it correctly.
\n\u2022\tUse dynamic SQL of DDL statements (such as CREATE, DROP, and ALTER)
\n\u2022\tIdentifiers in SQL statement such as names of columns, tables, schemas, database links, packages, procedures, and functions can’t be parameterized.
\n\u2022\tLegacy 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<\/p>\n

### Our tool that used to preventing SQL Injection<\/a><\/h3>\n

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.<\/p>\n

Let take a look at how our tool analyze the SQL to check for some of the above cases that indicate SQL injection.<\/p>\n

Case 1, where clause has been short-circuited<\/p>\n

###

###

###

    Injected SQL:\r\nselect col1  from table1 where col1 > 1 or 1=1\r\n\r\nSQL injected detected:\r\nalways_true_condition found! \r\n<\/pre>\nCase 2<\/p>\nInjected SQL:\r\nselect col1  from table1 where col1 > 1 and 1=2\r\n\r\nSQL injected detected:\r\nalways_false_condition found!\r\n<\/pre>\nCase 3, the where clause has been truncated with a comment<\/p>\nInjected SQL:\r\nselect col1  from table1 where col1 > 1; -- comment at the end of sql statement, maybe a sql injection\r\n\r\nSQL injected detected:\r\ncomment_at_the_end_of_statement found!\r\n<\/pre>\nCase 4, Stacking Queries, Executing more than one query in one transaction<\/p>\nInjected SQL:\r\nselect col1  from table1 where col1 > 1; update table2 set col1=1\r\n\r\nSQL injected detected:\r\nstacking_queries found!\r\n<\/pre>\nCase 5, the addition of a union has enabled the reading of a second table or view<\/p>\nInjected SQL:\r\nselect col1  from table1 where col1 > 1 union select col2 from table2\r\n\r\nSQL injected detected:\r\nunion_set found!\r\n<\/pre>\nCase 6, an unintentional SQL statement has been added.<\/p>\nInjected SQL:\r\nselect col1  from table1 where col1 > 1; drop table t1;\r\n\r\nSQL injected detected:\r\nnot_in_allowed_statement found!\r\n<\/pre>\nHow to use this tool in your application<\/h3>\nBoth Java and C# API of this tool are available, can be easily incorporated into your existing application with less performance impact. <\/p>\nJust validate dynamic SQL query like this:<\/p>\n\r\nstring sqltext= \"SELECT * FROM Users WHERE UserName = '\" + username + \"' AND UserPassword = '\" + password + \"'\";\r\n\r\nSQLInjection.isInjected(sqltext);\r\n\r\n<\/pre>\nOnline SQL injection detector<\/a><\/p>\nJavadoc is here<\/a><\/p>\nDownload Java source code of this anti SQL Injection tool<\/a><\/p>\nDownload SQL Injection tool with C# source code<\/a><\/p>\nSQL Injection tool with ANSI C source code<\/a><\/p>\nWe 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”)<\/p>\nModify this tool to add you own filter or rule<\/h3>\nThis 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
    \n\u2022\tdetect access is made to system tables
    \n\u2022\tbuilt-in or bespoke package procedures are called where they should not be.
    \n\u2022\tSQL where an unintentional sub-select has been added
    \n\u2022\tlogging injected SQL for system audit<\/p>\nContact information<\/h3>\nNeed 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”.<\/p>\n","protected":false},"excerpt":{"rendered":"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: \u2022 SQL where the where clause has been short-circuited by the addition of a line such as ‘a’=’a’ or 1=1 \u2022 SQL where the where clause has been truncated with a comment i.e —\u2026<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"open","template":"gsp_sql_translate_tt.php","meta":[],"blocksy_meta":{"styles_descriptor":{"styles":{"desktop":"","tablet":"","mobile":""},"google_fonts":[],"version":5}},"yoast_head":"\nAnti SQL Injection Tool<\/title>\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n