SLEEP(x) role in SQL query clarification - mysql

Question

I don't understand the reason why this happens.
Could somebody explain it?
SELECT * FROM users WHERE name = ''
returns 0 records as it should
SELECT * FROM users WHERE name = 'janet'
returns 1 record as it should
SELECT * FROM users WHERE name = ''-SLEEP(3)
returns EVERY record in the table, why??
SLEEP(3) returns 0
using name = ''-0 produces the same result (returning every record)
This is not for practical use it's because I'm testing time-based SQL injections

Answer 1

The documentation for the sleep function states:
Sleeps (pauses) for the number of seconds given by the duration argument, then returns 0. If SLEEP() is interrupted, it returns 1. The duration may have a fractional part.
So it returns an integer, so what you actually have is '' - 0, here '' is implicitly converted to an integer so the two types are comparable, so you then have 0 - 0 which equals 0, so your where clause is actually:
WHERE Name = 0;
Since you are comparing a string with an integer, type conversion must take place. Below is from the MySQL Docs
The following rules describe how conversion occurs for comparison operations:
If one or both arguments are NULL, the result of the comparison is NULL, except for the NULL-safe <=> equality comparison operator. For NULL <=> NULL, the result is true. No conversion is needed.
If both arguments in a comparison operation are strings, they are compared as strings.
If both arguments are integers, they are compared as integers.
Hexadecimal values are treated as binary strings if not compared to a number.
If one of the arguments is a TIMESTAMP or DATETIME column and the other argument is a constant, the constant is converted to a timestamp before the comparison is performed. This is done to be more ODBC-friendly. Note that this is not done for the arguments to IN()! To be safe, always use complete datetime, date, or time strings when doing comparisons. For example, to achieve best results when using BETWEEN with date or time values, use CAST() to explicitly convert the values to the desired data type.
If one of the arguments is a decimal value, comparison depends on the other argument. The arguments are compared as decimal values if the other argument is a decimal or integer value, or as floating-point values if the other argument is a floating-point value.
In all other cases, the arguments are compared as floating-point (real) numbers.
Since you have one argument that is a string, and one that is an integer it is the final clause that takes place. Converting a string (that is not a number) to a floating point number yields causes an err 0, which you can test using something as simple as:
SELECT CAST('A String' AS DECIMAL(10,5));
Which will give you 0.00000. So your final where clause after conversions have taken place is:
WHERE 0 = 0;
So all rows are returned.

Answer 2

MySQL is truncating the varchar value and is evaluating 0=0 in the Where clause. Execute the query and then execute show warnings; to see that the varchar values are truncated.
MySQL implicit conversions: http://dev.mysql.com/doc/refman/5.5/en/type-conversion.html

Answer 3

In MySQL, SLEEP() is a function that returns 0.
The documentation says it returns 1 when it is interrupted but it does not explain how this behaviour could be achieved. I thinks it's safe to assume it always returns 0 for this discussion.
The WHERE expression name = '' - SLEEP(3) is evaluated as follows:
MySQL calls the SLEEP(3) function; three seconds later it returns the integer value 0;
'' - 0 (the empty string minus zero) is evaluated as a numeric expression (the subtraction operator is not defined for strings); the empty string is converted to number 0, the value of the expression is the number 0 (zero);
the WHERE clause becomes name = 0 where 0 is a number.
The documentation page about Type Conversion in Expression Evaluation contains a list of rules used to convert the values of different types when they are compared:
The following rules describe how conversion occurs for comparison operations:
If one or both arguments are NULL, the result of the comparison is NULL, except for the NULL-safe <=> equality comparison operator. For NULL <=> NULL, the result is true. No conversion is needed.
If both arguments in a comparison operation are strings, they are compared as strings.
If both arguments are integers, they are compared as integers.
Hexadecimal values are treated as binary strings if not compared to a number.
If one of the arguments is a TIMESTAMP or DATETIME column and the other argument is a constant, the constant is converted to a timestamp before the comparison is performed. This is done to be more ODBC-friendly. Note that this is not done for the arguments to IN()! To be safe, always use complete datetime, date, or time strings when doing comparisons. For example, to achieve best results when using BETWEEN with date or time values, use CAST() to explicitly convert the values to the desired data type.
A single-row subquery from a table or tables is not considered a constant. For example, if a subquery returns an integer to be compared to a DATETIME value, the comparison is done as two integers. The integer is not converted to a temporal value. To compare the operands as DATETIME values, use CAST() to explicitly convert the subquery value to DATETIME.
If one of the arguments is a decimal value, comparison depends on the other argument. The arguments are compared as decimal values if the other argument is a decimal or integer value, or as floating-point values if the other argument is a floating-point value.
In all other cases, the arguments are compared as floating-point (real) numbers.
As you can see from this list, the last rule is the one that applies to the WHERE clause name = 0. Both operands are converted to floating point numbers.
Converting a string to an integer or floating point number will produce 0 the string is not the representation of a number.
This is the explanation of the apparently weird behaviour of your query.