MySQL comparison catch: ‘abc’ = 00

Petr 'PePa' Pavel — Mon, 25 May 2009 20:39:00 +0000

I was shocked to find a weakness in my authentication library today. It was possible to get around the password check if you knew the username. All you had to do was to enter 00 as the password. Or you just entered 00 as the username too and you got authenticated as the first user.

The bug was a combination of these three things:

A password (or/and username) that doesn’t contain any numbers
MySQL type conversion in conditions – when comparing a VARCHAR column to an INTEGER value it converts VARCHAR to INTEGER, not the other way around.
My own database wrapper was trying to be smart and didn’t wrap numeric values with apostrophes

Consider this template:

SELECT 1 FROM my_users WHERE (username = %s) AND (password = %s)

and something along these PHP lines:

if ($_REQUEST[‘username’] && $_REQUEST[‘password’]) {
// will catch 0 but not 00
if (mysqlValue($sqlTemplate, $_REQUEST[‘username’], $_REQUEST[‘password’]) {
echo ‘welcome’;
} else {
echo ‘wrong password’;
}
}

I won’t go into details about mysqlValue(). The important part is that it checks for special cases of NULL, true, false and is_numeric() and runs the rest through mysql_real_escape_string(). Then it inserts all parameters into the template using vprintf().

The problem is with is_numeric(). After being evaluated as a numeric value, ’00′ is entered into the query without apostrophes.

SELECT 1 FROM my_users WHERE (username = ‘my_username’) AND (password = 00)

And because any varchar that doesn’t contain a number compared to an integer is evaluated as true the result is a catastrophe.

'abc' = 00 is evaluated as true. 'abc1' = 00 would be false however, unfortunately only few users append a number to their password. If you use 00 for both the username and the password you get authenticated as the first user who didn’t do so.

Check out this false bug report or the related documentation page.

Why you could want to pass numeric values without apostrophes

I wonder myself :-) Here are some reasons I remembered:

I need to pass NULL in some cases and for that I can’t use %d
Using apostrophes for integer comparison (1 = ’1′) means unnecessary type conversion that takes time. A small amount of time but still.
An argument for abandoning the is_numeric() code: Using %d and %s in SQL templates provides a visual clue about what values can be expected there. But then I couldn’t insert NULL values.

So how to fix this mess?

What do you think? Should I remove the is_numeric() test and replace all %d with %s in all SQL templates? Remember that printf("%d", "'123'") will return 0.
Or should I keep the is_numeric() test and rewrite vulnerable queries to use for example CAST:

SELECT 1 FROM my_users WHERE (username = CAST(%s AS CHAR)) AND (password = CAST(%s AS CHAR))

Update 2010-01-18: I added the real reason for wanting to preserve %s in the template.

Update 2010-01-20:
Unfortunately, what I thought to be a solution (CAST(%s AS CHAR)) has another flaw – strips leading zeroes from the username / password which results into authentication failure.
So dear reader, any ideas?

How to deal with IMMUTABLE error in indexes that work with timestamps

Petr 'PePa' Pavel — Wed, 19 Mar 2008 12:14:54 +0000

Say that in an older version of PostgreSQL you had an index like this:

CREATE INDEX logTypeDay ON myLog (eventType, date_trunc(‘day’, creationTime));

and now after upgrading to 8.1+ you’re getting:
ERROR: functions in index expression must be marked IMMUTABLE

The reason is that date_trunc may return different results based on the current time zone. There’s an example query in PostgreSQL Mailing List Archives that you can run to believe.

If you are absolutely sure that you will always access your data with the same time zone you can redefine your index like this:

CREATE INDEX logTypeDay ON myLog (eventType, date_trunc(‘day’::text, creationTime AT TIME ZONE ‘Europe/Prague’));

The whole immutable business with indexes containing functions that process timestamps is well explained in these threads:
http://archives.postgresql.org/pgsql-interfaces/…/msg00045.php
http://www.webservertalk.com/archive307-2007-2-1817943.html
http://www.mydatabasesupport.com/forums/…-possible.html

All credit goes to Tom Lane. I admire him for being always so patient and polite, and for spending so much of his valuable time with talking to users. I would love to link to his homepage but I failed to find it.

Yet another blog about PHP, HTML and CSS » Database

MySQL comparison catch: ‘abc’ = 00

Why you could want to pass numeric values without apostrophes

So how to fix this mess?

How to deal with IMMUTABLE error in indexes that work with timestamps