I used this trick already to circumvent the PHPIDS filters in some earlier versions and mentioned it shortly in my article about MySQL Syntax. However when I used the same trick to circumvent the GreenSQL database firewall I noticed that this MySQL “bug” is not well known and so I decided to shortly write about it.
Take a look at the following unsecure SQL query:
SELECT * FROM table WHERE username = ‘$username‘ and password = ‘$password‘
Everyone knows about the simple authentication bypass using ‘ OR 1=1/* as username or perhaps ‘ OR 1=’1 for both inputs. But what MySQL allows too is a direct comparisons of 2 strings:
SELECT * FROM table WHERE username = ‘string’=’string‘ and password = ‘string’=’string‘
Therefore you dont need any Operators like “OR” which are mostly detected by filters. To shorten your vector you can also use an emtpy string, narrowing your SQL injection to:
Which ends in:
SELECT * FROM table WHERE username = ‘‘=’‘ and password = ‘‘=’‘
and successfully bypasses authentication on MySQL. Of course you can use other operators then “equal” and use whitespaces and prefixes to build more complex vectors to circumvent filters. Please refer to the MySQL syntax article. I have also tested this behavior on MSSQL, PostgreSQL and Oracle which does not have the same behavior.
What MySQL seems to allow is a triple comparison in a WHERE clause. That means you can use:
SELECT * FROM users WHERE 1=1=1
SELECT * FROM users WHERE ‘a’=’a’=’a’
Interestingly the following queries also work:
SELECT * FROM users WHERE ‘a’=’b’=’c’
SELECT * FROM users WHERE column=’b’=’c’
SELECT * FROM users WHERE column=column=1
That means if you compare strings it doesnt matter if they are equal and it seems like if you compare columns with Strings or Integers they will get typecasted.
Lastly I would like to recommend a great article from Stefan Esser about another authentication bypass on MySQL.
MySQL does not consider this as a bug. Please refer to the bugreport for detailed information. Again this shows how flexible the MySQL syntax is (intentionally).
Informative post. But is there any way to disable this or prevent this usage?
yes, just prevent SQL Injection vulnerabilities at all by proper escaping or prepared statements.