Comments on: MySQL input/output validation

By: Reiners

Reiners — Sat, 07 Jun 2008 13:36:06 +0000

hey raz0r,
there has been some discussion on is_numeric() on sla.ckers here. although we found no example how to exploit it, I agreed with Mordred that hex numbers should not be accepted if you expect integers only (which is a common case for SQL input).

greetings,
Reiners

By: raz0rname

raz0rname — Sat, 07 Jun 2008 13:14:29 +0000

Nice function, but why don’t you use is_numeric() instead of ctype_digit()? is_numeric() is commonly used in such cases. I have written a function that checks user input, have a look if you are interested (the post is in Russian, but i guess we both speak PHP
http://raz0r.name/releases/funkciya-dlya-obrabotki-vxodyashhix-dannyx/

By: Reiners

Reiners — Tue, 13 Nov 2007 22:52:39 +0000

Ok I see your point with the type cast and changed it back to the original intval() . But actually we could take it out completly if we trust ctype_digit() I think.
As far as I’ve tested ctype_digit – it does return true/false, just like the php manual says so I see no problem there, or am I missing something?

By: .ﻩﻨﺮﻪﺴ

.ﻩﻨﺮﻪﺴ — Tue, 13 Nov 2007 22:17:27 +0000

I don’t really agree with the typecast. You normally cast when you want to make sure that something that’s supposed to be of a certain type will really be of that certain type (like you need 1 – even if it’s coming in as “1″).

When dealing with user generated content you might expect anything – so a typecast is pretty useless. I think especially when facing potential SQLI there’s nothing else that validation. If that fails the probability is 90+% sure that something wnet wrong – so why casting in those cases?

Ah – and never forget – I stepped into this trap myself some times – ctype_digit returns the incoming string – not true. Might produce evil surprises especially when dealing with unit tests

Greetings,
.mario

By: Reiners

Reiners — Mon, 12 Nov 2007 17:35:36 +0000

thanks again for your input .mario! I changed is_int() to ctype_digit() because int’s come in as string, you’re right.
But I still think that if you decide to truncate data (which isn’t neccessary) it should be the first thing you do.
Additionally I replaced intval() with a type cast (int) because I couldn’t find out any difference, but its one function less we have to trust.
What do you think?

By: .ﻩﻨﺮﻪﺴ

.ﻩﻨﺮﻪﺴ — Mon, 12 Nov 2007 16:43:28 +0000

I’d rather suggest to chose validation over truncation. If you deal with IDs you most times get integers (coming in as string when user submitted) – so you can chose is_numeric() or ctype_digit().

By: Reiners

Reiners — Mon, 12 Nov 2007 00:52:09 +0000

I just added the truncation to make clear that you should truncate at first before you do other sanitizing. As seen in the added sla.ckers link, one may add the truncation at the wrong place. But you are right, it’s not neccessary. However it can protect the used php functions (we have to trust) against BoF or alike, if you know your input is going to be not longer than a fixed value anyway.
As far as I’ve tested, mysql query fails with entities in the mysql syntax. There is no decoding inside the query or a quoted value.

Thanks for your input, really appreciated. I thought my blog is quite unknown yet, though I didnt raise any attention because theres not much to read about yet and even the published articles need a finish .

By: .ﻩﻨﺮﻪﺴ

.ﻩﻨﺮﻪﺴ — Sun, 11 Nov 2007 19:42:25 +0000

Hmmm – why the truncation? Also it should be pointed out that mysql_real_escape_string can’t be used in any case.

I winder how MySQL reacts on quotes encoded ans hex entities – do you have any info on that?

Greetings,
.ﻩﻨﺮﻪﺴ