Forum d'entraide PHPFrance

Bonjour à tous ceux qui ne prenne pas de jours de congés!!
Je viens vers vous avec une interrogation.
Débutant en php et développant un site avec apache, je ne me suis pas vraiment soucié des extensions php ou module comme les magic quotes. Mais comme j'en viens à la phase de mise en ligne de mon site, j'ai commencé à creuser la question.
J'ai réalisé mon site avec les magic quotes gpc activé puisqu'il se met sur "on" par défaut et malheureusement je viens de voir que sur l'hebergeur que j'avais choisi les magic quotes ne le sont pas.

Je voulais donc savoir les conséquences que cela pouvait entrainer sur mon site et les éléments à mettre en place pour que mon site fonctionne avec les magic quotes désactivé.

J'ai fait des recherches sur internet et je suis tombé sur des articles qui parlaient de mysql_real_escape_string() ou encore addslashes() mais j'avoue ne pas savoir ou mettre ses fonctions et si elles sont bien appropriées.

Merci par avance pour toute aide apportée.

En fait, l'option magic_quotes va automatiquement, pour toutes les variables récupérées par php, protéger apostrophes, guillemets, etc. par des antislashes. Le principal intérêt, c'est de pouvoir les injecter directement dans une requête SQL sans avoir à les protéger soit même :

$sql = "UPDATE ... SET champ = '".$var."'";
// avec magic quotes
echo $sql; // affiche : UPDATE ... SET champ = 'L\'exemple'
// sans magic quotes :
echo $sql; // affiche : UPDATE ... SET champ = 'L'exemple'

Sans les Magic Quotes, si tu ne fais rien, il y aurait une erreur de syntaxe, puisque SQL considèrera que la chaine s'arrête après le L. Entre parenthèse, c'est également une faille de sécurité si tu ne fais rien, puisque l'on peut volontairement envoyer une apostrophe pour fermer la chaine et enchainer avec un bout de code SQL malicieux.

Un exemple concret :

si tu testes l'authentification d'un utilisateur ainsi : "WHERE login = '".$login."'" 
et que je me logue avec le login : "' OR '1'='1"
le test sera : "WHERE login = '' OR '1'='1'"
ce qui sera toujours vrai et me voilà utilisateur reconnu et authentifié :)

mysql_real_escape_string() a donc pour but de protéger ta chaine pour éviter ces "injection sql" :

$sql = "UPDATE ... SET champ = '".mysql_real_escape_string($var)."'";

Ce n'est bien sur qu'un exemple parmi d'autres Après on peut aussi bricoler un truc pour qu'au début de ton script, il fasse un addslashes() sur chaque variable que tu récupères si le magic quotes est désactivé, mais ca devient déjà plus du bricolage

Il faut mettre toutes ces fonctions sur la ligne de requête lorsque tu enregistres quelque chose en BDD.
genre:
$sql=addslashes('ta_requete_sql');

Plus loin lorsque tu ressortiras un résultat de la BDD, il faudra alors mettre un stripslashes().

Mais bon, ce n'est pas toujours évident, on s'emmêle parfois les pinceaux.

Euh... objection votre honneur !!

Ce n'est surtout pas toute la requête qu'il faut protéger avec addslashes, mais uniquement les variables (et encore, seulement les chaines en thérorie, mais comme mysql autorise les apostrophes autour des nombres, faut tout protéger)
Le but est juste de générer une chaine de caractères qui peut être intereprété par le sgbd. Avec des antislash partout, il ne saura jamais ou commencent les chaines.

Et il n'est absolument pas nécessaire de faire un stripslashes() pour lire les données qui ont été insérés, le sgbd sait très bien que si un caractère est protégé d'un antislash, il ne doit insérer que le caractère et pas l'antislash.

Euh... objection votre honneur !!

Ce n'est surtout pas toute la requête qu'il faut protéger avec addslashes, mais uniquement les variables (et encore, seulement les chaines en thérorie, mais comme mysql autorise les apostrophes autour des nombres, faut tout protéger)
Le but est juste de générer une chaine de caractères qui peut être intereprété par le sgbd. Avec des antislash partout, il ne saura jamais ou commencent les chaines.

Et il n'est absolument pas nécessaire de faire un stripslashes() pour lire les données qui ont été insérés, le sgbd sait très bien que si un caractère est protégé d'un antislash, il ne doit insérer que le caractère et pas l'antislash.

Oulà (3615) effectivement j'ai été trop vite! Faudra que je me dérouille!

Entre mysql_real_escape_string() et addslashes(), je suis parti sur la première solution pour le moment.
Est-ce un bon choix ou fallait-il privilégier la seconde?