SQL injection

Pour ceux qui avaient commencé le challenge pointé par Nicob[1] (et pour les
autres) il y un message sur bugtraq qui est interressant.
Désolé je suis trop limité en temps pour traduire le message que je reprends
dans son intégralité ci dessous.
Basiquement SQL Serveur quote différement de MySQL ce qui permet du SQL
injection plus facilement quand le programmeur n'a pas fait gaffe.

Petit rappel au passage pour éviter le gag : évitez de trop faire confiance
aux sécurités "intégrées" dans php, perl etc. et effectuez vous même un
parsing des entrées utilisateurs. En plus une fois écrite la fonction est
réutilisable, alors à quoi bon s'en priver?

Eric.

[1] Grrr j'ai bloqué comme un andouille au niveau 3 et j'ai plus des masses
de temps la :)

----- Original Message -----
From: "Martin Sarsale (runa@sytes)" <runa@runa.sytes.net>
To: <bugtraq@securityfocus.com>
Sent: Thursday, December 04, 2003 8:39 PM
Subject: Intresting case of SQL Injection

> Yesterday, we found an interesting case of SQL Injection.
>
> The application was developed under PHP 4.2.1, Apache and MSSQL.
>
> We started our tests by adding a ' (single quote) to the POST info.
>
> Since PHP escapes ' and " , turning the ' into a \' but SQL Server uses 2
> single quotes ('') to escape a quote (') we were allowed to execute our
> code:
>
> select * from users where username='\'; sql code to execute here;--
>
> Then, we wanted to insert a record on the "users" table (fields username
> and password, both varchar).
>
> We found that the application used md5 to store the user passwords but
> there was a problem: since PHP was auto escaping quotes, we couldn't set
> the md5 password as a string because sending:
>
> insert into users values ('username','password');
>
> would be escaped into
>
> insert into users values (\'username\',\'password\');
>
> resulting in a sql error.
>
> So, we had to figure out how to insert the username and password as
> numeric values. Since both fields are varchar, when inserting a number SQL
> server will cast the number into a string.
>
> This is:
> inserting 123 (numeric) into a varchar field is the same as inserting
> '123' (string).
>
> The username part is easy, we could insert '12345' as the username (any
> number will work here), but we found a problem with the password: We need
> a known string which it's md5 hash is ALL NUMERIC.
>
> Then, we coded a simple PHP script and found that md5(1518375) =
> 93240121540327474319550261818423
>
> After that, we sent to the app:
>
> '; insert into users (username,password) values
> (12345,93240121540327474319550261818423);--
>
> which escaped became into:
>
> \'; insert into users (username,password) values
> (12345,93240121540327474319550261818423);--
>
> (valid SQL)
>
> Finally, we logged into the webapp using '12345' as username and '1518375'
> as password.
>
> The main problem here was that developers where trusting in PHP auto
> escaping which worked in MySQL (and probably PostgreSQL) but not in MSSQL.
>
> Alejandro Pomeraniec (apomeraniec at buenosaires.gov.ar)
> Martin Sarsale (msarsale at buenosaires.gov.ar)