Kioob
mercredi 19 septembre 2007 à 15:12
Hello,
je vais tenter d'éclaircir un peu tout ça vu que cela semble encore flou.
Pour commencer prenons une requete SQL classique, faite au sein de PHP :
CODE
$requete = "select nom, prenom, email from utilisateur where login = '$login' and password = '$password' ";
Rien d'extraordinaire jusque là. Maintenant imaginons qu'un vilain visiteur ne saisisse pas un mot de passe classique mais quelque chose contenant des apostrophes... par exemple :
toto' OR '1' ='1On obtiendra donc la requete :
CODE
select nom, prenom, email from utilisateur where login = 'bidule' and password = 'toto' OR '1' ='1'
Et là aïe, ça coince : peu importe le mot de passe, la requête retournera un résultat. Et évidement, il y a bien d'autres possibilités.
L'idée de départ des "magic_quotes_gpc" était donc de se protéger de cela. Sauf que cela pose deux soucis : premièrement, magic_quotes_gpc se contente de faire un bête un addslashes() sur toutes les données, ce qui est loin d'être suffisant pour se protéger des injections SQL. Et secondement, magic_quotes_gpc est bête et méchant : il fait un addslashes() sur toutes les données entrantes, alors qu'il est rare qu'elles ne servent qu'à produire des requetes SQL.
Au final, pour vraiment se protéger d'une injection SQL on est donc obligés de faire un "stripslashes" (pour récupèrer la variable d'origine) suivi d'un mysql_real_escape_string (qui est la seule fonction échappant correctement les données pour MySQL). Galère non ?
Sans oublier que si vous voulez utiliser votre variable pour autre chose qu'une requete SQL, il faudra également y aller à coup de stripslashes...
Voilà pourquoi c'est supprimé de PHP 6 : les développeurs se croient à l'abri en utilisant cette "fausse sécurité" alors qu'il n'en est rien. Un comble non ?
La solution ? Désactiver magic_quotes_gpc, et toujours penser à utiliser mysql_real_escape_string quand c'est nécessaire.
Pour ce qui est de la portabilité du code, j'ai donc opté pour le contraire de la solution ci dessus : je fais des stripslashes sur toutes les données en entrée si magic_quotes_gpc était actif.
Ainsi cela implique un traitement supplémentaire (le stripslashes) que sur les serveurs "mal" configurés (1).
Cela donne par exemple :
CODE
<?php
if( get_magic_quotes_gpc() )
{
gpc_walk( $_GET, 'stripslashes' );
gpc_walk( $_POST, 'stripslashes' );
gpc_walk( $_COOKIE, 'stripslashes' );
gpc_walk( $_REQUEST, 'stripslashes' );
}
function gpc_walk( & $array, $fct )
{
foreach( $array as $key => $item )
{
if( is_array( $item ) )
{
gpc_walk( $array[$key], $fct );
}
else
{
$array[$key] = $fct( $item );
}
}
}
?>
Voilou
(1) dans le cas d'un hébergement mutualisé, où l'on ne contrôle pas les scripts utilisés par le client, activer magic_quotes_gpc reste malgré tout le meilleur choix à mon avis :
- de toutes façons les scripts "bien fait" gèrent ça correctement
- si le script n'en tient pas compte, il vaut toujours mieux avoir une sécurité relative (addslashes) qu'aucune.
