I have received a few emails from people asking me to explain what i mean by this and when could this be useful. Firstly, this is nothing new and probably everyone understands it under 'Difficult boolean logic' sql injection category. Anyways, here's a better explanation and a more realistic example:
Imagine a php script taking user's input in construction of 2 sql queries:
$sql_1="select foo from bar where uid =5 and id =' ". $_GET['id']. " ' ";
$sql_2="select foo2 from bar2 where id in (' ". $_GET['id']. " )' ";
So, the same input goes into 2 different sql query. One in parenthesis() and one without parenthesis. Next, consider that the application logic is such that it only checks if sql query returned any rows or not. So, when the sql query is true (no errors) and irrespective of how many rows returned the application returns some page and returns a different error page when there is a SQL error. In this example, it is difficult to use the comments(--) to ignore part of the query, as the input goes in parenthesis in one instance only. Hence, i think the use of union is not possible.
Now, you could you use the case statement to throw errors('sql error: subquery returned more than one row'), whenever the SQL query is false, thus making a boolean logic blind SQL Injection.
select foo from bar where uid =5 and id = ' injection' and (case when (1=1) then 1 else 1*(select table_name from information_schema.tables)end) and '1'='1 ';
select foo2 from bar2 where id in (' injection' and (case when (1=1) than 1 else 1*(select table_name from information_schema.tables)end) and '1'='1 ')
In the above example, only the first query will return the sql error when there is a flase condition (e.g. 1=2), while the second query is just syntactically correct. So, now you could replace the (1=1) and (1=2) with you boolean logic SQL string and extract data.
Further, in one of the slides at OWAPS AU i mentioned about the areas which generally get missed by automated SQL Injection scanners. The above example, is one such scenario which automated tools will generally miss. Recently, i have seen a few applications, where the form parameters name is used in sql query.
so imagine a URL like:
Now, its a common practice to fuzz the parameter value (books) and not so many tools will fuzz the parameter name. Recently, i have seen a few SQL injections in parameter name:
vuln.com/vuln.php?product_id[234' or '1'='1]=books
Hope this helps...