injection (My)sql avec php

La réponse est oui, tu trouveras beaucoup de docs là dessus en
cherchant un peu...

Peut on craindre des injections sql avec php bien que comme c'est le cas
par défaut dans php.ini l'option "magic_quotes_gpc" soit sur ON.

$_REQUEST['entier']="0 OR 1=1";

$dad=mysql_connect(...); // et test retour
$sel=mysql_select_db(....,$dad); // et test retour
$query="DELETE FROM toto WHERE id=$entier";
$res=mysql_query($query,$dad);
if($res=úLSE) exit(mysql_error($dad));
echo mysql_affected_rows($dad);
echo "Oh Fuck...";

"christov" <christov@altern.org> a écrit dans le message de news:
42a6a4cb$0$4851$636a15ce@news.free.fr...

Peut on craindre des injections sql avec php bien que comme c'est le cas
par défaut dans php.ini l'option "magic_quotes_gpc" soit sur ON.

Bonjour,

Je doute que cette seule protrection soit un rempart.

Pour plus de détails sur la question, un certain nombre de sites traitent de
ce sujet.

Notamment :
http://www.phpsecure.info/v2/article/InjSql.php
mais aussi :
http://www.linux-pour-lesnuls.com/injection.php

Salutations.

Peut on craindre des injections sql avec php bien que comme c'est le cas
par défaut dans php.ini l'option "magic_quotes_gpc" soit sur ON.

$_REQUEST['entier']="0 OR 1=1";

$dad=mysql_connect(...); // et test retour
$sel=mysql_select_db(....,$dad); // et test retour
$query="DELETE FROM toto WHERE id=$entier";
$res=mysql_query($query,$dad);
if($res=úLSE) exit(mysql_error($dad));
echo mysql_affected_rows($dad);
echo "Oh Fuck...";

S'il s'agit d'un entier, c'est tout simple, utiliser le transtypage
(http://www.php.net/manual/fr/language.types.type-juggling.php#language.types.typecasting)
:

$query = 'DELETE FROM `toto` WHERE id='.(int) $entier;

Peut on craindre des injections sql avec php bien que comme c'est le cas
par défaut dans php.ini l'option "magic_quotes_gpc" soit sur ON.

$_REQUEST['entier']="0 OR 1=1";

$dad=mysql_connect(...); // et test retour
$sel=mysql_select_db(....,$dad); // et test retour
$query="DELETE FROM toto WHERE id=$entier";
$res=mysql_query($query,$dad);
if($res=úLSE) exit(mysql_error($dad));
echo mysql_affected_rows($dad);
echo "Oh Fuck...";

Perso, je suis partisan de quoter même les valeurs numériques ( certains
vont s'énerver, mais ça fonctionne ).

$query = 'DELETE FROM toto WHERE id = ''.$entier.'''; // cas du magic
quotes à on

$query = 'DELETE FROM toto WHERE id = ''.mysql_real_escape_string(
$entier ).'''; // cas du magic quotes à off

Ceci étant dit, une bonne pratique est de vérifier la cohérence des
informations fournies par l'utilisateur, ceci afin d'assurer la
cohérence de l'application:
- si une variable doit être numérique, vérifier qu'il n'y a que des nombres
- si une variable ne doit contenir que des chiffres et des lettres, s'en
assurer ...

et renvoyer le formulaire à l'utilisateur si des données sont erronées.

De cette façon, 90% des tentatives d'injection SQL sont écartées, il ne
reste plus que quelques cas spéciaux à traiter.

PS: pas la peine de recommencer le débat de l'autre jour et de voir des
injections SQL ou il n'y en a pas.

On 2005-06-08, John Gallet <john.gallet@wanadoo.fr> wrote:

$_REQUEST['entier']="0 OR 1=1";

$query="DELETE FROM toto WHERE id=$entier";

Une très belle démonstration, John :)
Où en est ton document sur la sécurisation des applications web
qui a enflammée fcs il y a quelques mois ?

--
_/°< coin

Perso, je suis partisan de quoter même les valeurs numériques ( certains
vont s'énerver,
A juste titre.

mais ça fonctionne ).
Oui, très bien même (je parle de la faille, pas de la protection).

- si une variable doit être numérique, vérifier qu'il n'y a que des nombres
C'est la SEULE et unique solution (par exemple en castant).

PS: pas la peine de recommencer le débat de l'autre jour et de voir des
injections SQL ou il n'y en a pas.

Et où il y en a on la droit encore ?

mysql> create table titi (
-> colv varchar(10),
-> coli int);
Query OK, 0 rows affected (0.00 sec)

mysql> insert into titi values ('un',1);
Query OK, 1 row affected (0.00 sec)

mysql> update titi set colv='deux' where coli='1 or 1=1';

Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from titi;
+------+------+
| colv | coli |
+------+------+
| deux | 1 |
+------+------+
1 row in set (0.00 sec)

Temps du test : inférieur à une minute pour montrer que vous racontez des
âneries.

Donc les quotes pour les entiers c'est ***NON***.

JG

Une très belle démonstration, John :)

Un petit exemple simple.

Où en est ton document sur la sécurisation des applications web
qui a enflammée fcs il y a quelques mois ?

Au point mort :-(( Et ça me désole d'autant plus que j'en ai moi même
besoin de ce doc. Donc ça va finir par se pondre, mais là je n'y arrive
plus. J'ai lâché du lest sur la modération et participation à ce forum
pour retrouver un peu de temps, que j'ai investit dans la FAQ (là aussi,
j'ai beaucoup d'idées et peu de pétrole) mais ça avance pas terrible.

Sorry guys, ça viendra vite mais il faudra attendre longtemps...
JG

Peut on craindre des injections sql avec php bien que comme c'est le cas
par défaut dans php.ini l'option "magic_quotes_gpc" soit sur ON.

Oui, et cela regroupe plusieurs erreurs.

On vous a déjà donné de bons exemples, qui montrent bien que ce n'est ni
le ', ni le ; qui sont au coeur du problème.

Les bonnes règles:

1) ne jamais se baser sur les valeurs par défaut : en changeant
d'hébergement, votre option de configuration elle va peut être changer
Donc, partir par défaut dans l'idée qu'on est dans le cas le plus
défavorable, et tout refaire soi-même
(modulo le fait que sur l'histoire des quotes en PHP, il faut vérifier
l'état de l'option, car l'application des protections n'est pas une
opération idempotente)

2) vérifier le contenu des données qu'on manipule.
A ce sujet, plusieurs thèses s'affrontent: vérification en entrée du
système (dès qu'on reçoit les informations et bien avant qu'on les
utilise) ou en sortie (juste avant de les utiliser, par exemple quand on
va les transmettre au SGBDR).
Ce qui me semble le mieux: vérifier le plus tôt possible, en tout cas dès
qu'on estime qu'il ne sert à rien d'aller plus loin et d'entamer des
calculs couteux si les données sont mauvaises
*et* ne modifier les données pour être compatibles avec le nouveau
contexte[1] qu'au dernier moment, ie

Cette distinction peut semble subtile et/ou inutile, mais elle me parait
importante.

Cela peut aller aussi comme dans certains langages, mettre une
``étiquette'' aux données provenant de l'extérieur pour justement se
rappeler qu'il ne faut pas faire n'importe quoi avec ces données.

3) utiliser un SGBDR et une bibliothèque d'interconnexion qui permettent
d'utiliser les prepared statements car ces derniers
*) améliorent les performances (normalement)
*) améliorent la sécurité (en évitant la fusion de contexte justement, cf
[1])
Si l'on n'a pas cela à disposition, utiliser une bibliothèque qui est
capable de quoter correctement les données envoyées, en fournissant une
fonction idoine (genre quoteSmart dans PEAR DB). C'est moins bien car il
faut penser à l'appeler explicitement en général.

Cette troisième étape est *inutile* si l'étape numéro 2 n'a pas été
exécuté correctement.

Tout le reste, et notamment les modifications contre nature des requêtes
SQL, ce n'est que du bidouillage qui s'écroule rapidement contre une
attaque, comme tout bidouillage d'ailleurs. Et présenter l'étape 3 avant
d'avoir expliqué la nécessité de l'étape 2, c'est montrer une grave
incompréhension de la racine du mal.

En résumé, c'est très loin de:
utiliser addslashes ou utiliser mysql_escape_string
qui sont les idioties répétées à longueur de journée ici et ailleurs.
(sans compter que, pour le deuxième cas de figure, cela a tendance à
faire croire qu'il n'y a que MySQL dans la vie, ce qui n'est heureusement
pas le cas)

Tout ce qui précède n'a rien de spécifique à PHP, si ce n'est qu'il faut
encore plus faire attention à ces problèmes en PHP, qui part avec des
handicaps par rapport à d'autres langages (ex: register_globals).

Une fois tout ceci fait correctement (et c'est un *gros* travail le plus
souvent, même quand on dispose d'outils adéquats car, comme le disent les
experts, un programmeur n'a pas l'état d'esprit d'un attaquant et donc ne
voyant pas les attaques possibles sur le code en train d'être créé, il ne
voit pas non plus les défenses à mettre en oeuvre - d'où l'intérêt sur
les gros projets d'avoir une équipe pour l'audit indépendante de l'équipe
de développement), on peut passer à la deuxième étape: s'occuper des
attaques par rebond, et donc opérer le même soin pour ce qui vient de
l'utilisateur, que pour ce qui vient de la base de données, de
l'environnement, du système d'exploitation, d'une autre partie de
l'application, etc... Bref, faire une application protégée contre elle-même.

[1] une vision qu'on ne voit pas souvent et qui est une bonne clef je
trouve pour voir un certain nombre de problèmes de sécurité (on retrouve
en particulier tous les types d'injection, SQL, HTML, shell) est la
suivante:
quand des données passent d'un contexte à un autre ou que l'on a une
fusion implicite de contexte, *alors* il y a un risque de problèmes
(parce que dans chaque contexte, le contenu des données a un sens
différent, ainsi de certains caractères particuliers, et que si on change
de contexte, on change de sens)

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

- si une variable doit être numérique, vérifier qu'il n'y a que des nombres

C'est la SEULE et unique solution (par exemple en castant).

Je trouve que caster la variable n'est pas forcément la meilleure solution.

Le travail de vérification des variables doit se faire en amont et a
plus a voir avec la cohérence de l'application que la sécurité. Si on
fait un cast, on laisse le script s'exécuter alors qu'il y a incohérence
des données entrées par l'utilisateur, il devient alors difficile de
ramener une erreur précise à l'utilisateur.

[ SNIP ]

Temps du test : inférieur à une minute pour montrer que vous racontez des
âneries.

Bon, ça ne fonctionne pas chez moi ( MySQL 4.0.23 - Linux Debian ), mais
je saurais maintenant que certaines versions de MySQL sont vulnérables.

PS: pas la peine de recommencer le débat de l'autre jour et de voir des
injections SQL ou il n'y en a pas.

Et où il y en a on la droit encore ?

Et bien là, vous m'avez démontré qu'il y avait problème et je vous en
remercie, l'autre jour, l'intervenant voyait des problèmes ou il n'y en
avait pas.