Discussion :

[bond70]

Salut,

Voilà j'ai crée un formulaire d'ajout pour insérer des données (du texte) dans ma table SQL.

Le problème c'est que quand mon texte contient des ' la requête d'insertion me retourne une erreur.

Comment pourrais-je résoudre ce problème ?

merci !!!

[Thes32]

salut,

tu dois utiliser la fonction addslashes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
$data = addslashes( $data_initial );
$requete = "INSERT INTO my_table VALUES( '', '$data' )";
$result = mysql_query( $requete );

Edit : petite modif

[bond70]

Salut, maintenant il gueule à cause des simples cote dans la syntaxe de la requête elle-même

exemple ici :

SET texteChamp1='$texte'

merci!

[Thes32]

peux tu montrer un peu plus de code ?

[bond70]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$modifob="UPDATE observation SET texteObservation='$obs1', poursuiteObservation='$obs2' WHERE nomEtudiantObservation='$nom' AND prenomEtudiantObservation='$prenom' AND semestreEtudeId=$idsemestre";
$modifobs=addslashes($modifob);
$req = mysql_query($modifobs) or die('Erreur SQL !<br>'.$modifobs.'<br>'.mysql_error());

Il gueule à cause des simples côtes qui entoure les variables textuelle dans la requête

Exemple ici :

SET texteObservation='$obs1'

Erreur :

Erreur SQL !
UPDATE observation SET texteObservation=\"$obs1\", poursuiteObservation=\"$obs2\" WHERE nomEtudiantObservation=\"$nom\" AND prenomEtudiantObservation=\"$prenom\" AND semestreEtudeId=$idsemestre
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\"$obs1\", poursuiteObservation=\"$obs2\" WHERE nomEtudiantObservation=\"$nom\" ' at line 1

[Thes32]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
$obs1 = addslashes( $obs1 );
$obs2 =  addslashes( $obs2 );
$nom =  addslashes( $nom );
$prenom =  addslashes( $prenom );
$modifob="UPDATE observation SET texteObservation='$obs1', poursuiteObservation='$obs2' WHERE nomEtudiantObservation='$nom' AND prenomEtudiantObservation='$prenom' AND semestreEtudeId=$idsemestre";
$req = mysql_query($modifobs) or die('Erreur SQL !<br>'.$modifobs.'<br>'.mysql_error());

[bond70]

A ouais je m'en doutais, il faut faire çà pour chaque champs de la requête...

Heureusement que je n'ai pas trop de variables à modifier

merci!!

[RunCodePhp]

Re

Faut utiliser la fonction mysql_real_escape_string()
-> La doc (comme d'had ) : http://fr2.php.net/manual/fr/functio...ape-string.php

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
// Une variable $variable qui contiendrait cette chaine : Et l'affaire est réglé
mysql_query('INSER INTO table (champ1) VALUES (\''.mysql_real_escape_string($variable).'\')');
 
//Ou
mysql_query("INSER INTO table (champ1) VALUES ('".mysql_real_escape_string($variable)."')");

Mais de nos jour il y a une classe PDO qui permet de faire des requêtes préparées, du coup se simplifier la tâche avec tout ces histoires de quote et d'injection SQL.
Exemple :

$pdo = new PDO( bla bla bla );
$sth = $dbh->prepare('INSER INTO table (champ1) VALUES (:valeur1)');
$sth->bindValue(':valeur1', $variable, PDO:ARAM_STR);
$sth->execute();

[Thes32]

si tes variables proviennent d'un formulaire ou si elles sont reçues par get tu peux utiliser la fonction array_map

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
//échappe toutes les données du tableau $_POST
$_POST = array_map( 'addslashes', $_POST );
 
//échappe toutes les données du tableau $_GET
$_GET = array_map( 'addslashes', $_GET );

[RunCodePhp]

Je ne suis pas d'accord avec la fonction addslashes, et encore moins la généraliser avec POST ou GET.

D'une part, MySQL à prévue une fonction dédiée aux échappement et surtout pour lutter contre les SQL injections : mysql_real_escape_string() (ou on opte pour PDO)
Et d'autre part, appliquer un addslashes directe comme ça sur POST ou GET, on est pas à l'abri de provoquer d'autres problèmes en cascades.


Juste comme ça, qu'est ce que tu as comme config au niveau du php.ini pour la directive magic_quote_gpc ? (qui devrait être à Off ou 0)
La source de ton problème vient peut être de là, qui sait ?

[Thes32]

@RunCodePhp : mysql_real_escape_string() consomme beaucoup plus des ressources que addslashes et nécessite une connexion mysql soit ouverte.

[Thes32]

D'une part, MySQL à prévue une fonction dédiée aux échappement et surtout pour lutter contre les SQL injections : mysql_real_escape_string() (ou on opte pour PDO)

c'est tout ce que tu as comme argument pour être contre addslashes ?

Et d'autre part, appliquer un addslashes directe comme ça sur POST ou GET, on est pas à l'abri de provoquer d'autres problèmes en cascades.

Quel problème par exemple ?

Juste comme ça, qu'est ce que tu as comme config au niveau du php.ini pour la directive magic_quote_gpc ? (qui devrait être à Off ou 0)
La source de ton problème vient peut être de là, qui sait ?

Si magic_quote était activé il aurait pas eu ce problème.

[RunCodePhp]

@RunCodePhp : mysql_real_escape_string() consomme beaucoup plus des ressources que addslashes et nécessite une connexion mysql soit ouverte.

Peut être, voir surement.

Mais à l'époque ou j'utilisais les fonctions mysql_* (maintenant PDO donc plus du tout de genre de problème) je me rappelle d'avoir fait beaucoup d'essais entre ces 2 fonctions addslaches() et mysql_real_string() et j'en avais conclu qu'elles n'y faisaient pas totalement la même choses.
Mais ça fait longtemps, je ne pourrais plus dire quel cas, mais la fonction mysql_real_escape_string() m'avait parue plus efficace.
J'étais même amené à l'utiliser dans un tout autre contexte que pour la BDD car un mysql_real_escape_string n'avait pas d'égal.


Bref ... je ne suis pas convaincu qu'il faille se focaliser sur l'optimisation dans ce cadre là et abandonner une fonction qui pourtant est prévue pour.

M'enfin ... comme je l'ai dis, j'utilise PDO, je n'est donc plus de question à me poser.

Si magic_quote était activé il aurait pas eu ce problème.

Je peux lui poser quand même la question, ça ne mange pas d'pain.

[julp]

Je ne suis pas d'accord avec la fonction addslashes, et encore moins la généraliser avec POST ou GET.

+200000

addslashes n'est pas aussi stricte que mysql_real_escape_string, et surtout, addslashes ne prend pas en compte le jeu de caractères courant de la connexion.

Contre, également, une généralisation d'une quelconque protection en vue d'éliminer les injections sur toutes les données extérieures (GET/POST/etc) : elles ne sont pas forcément toutes destinées à la base de données et elles doivent être traitées uniquement par rapport à l'usage du moment. On ne traite pas de la même manière les données destinées à une requête (dont on dépend du SGBD d'ailleurs), d'une intégration à une expression régulière (preg_quote), etc. Un mécanisme automatique aurait plutôt tendance à induire un faux sentiment de sécurité et à introduire des erreurs (si c'est pour faire repasser ces données sur stripslashes, on n'est pas plus avancé).

Enfin, je rejoins, une nouvelle fois, RunCodePhp sur l'usage des requêtes préparées qui simplifient bien les choses, et à tous les niveaux (requiert PDO ou MySQLi).

[bond70]

Salut à tous,

Je vois que ma question porte à débat.

Voici les valeurs de "magic_quotes_gpc" dans mon php.ini (quelqu'un me les avait demandé) :

; magic_quotes_gpc
; Default Value: On
; Development Value: Off
; Production Value: Off

Je rappel que mon problème était d'insérer des données textuelle dans ma table à l'aide d'un formulaire. Ce formulaire envoi les valeurs saisies par l'utilisateur via $_POST à une page php qui les insères avec une requête UPDATE (voir plus haut).

L'idée de faire un traitement directement depuis le $_POST me paraissait pas mal. Mais on dirait que c'est pas si bien que çà selon vous.

Dois-je faire le traitement par la suite ou directement au niveau du $_POST ?

Merci !

[RunCodePhp]

; magic_quotes_gpc
; Default Value: On
; Development Value: Off
; Production Value: Off

Le problème c'est qu'on est pas plus avancé, car se que tu montre ce sont des commentaires, car dans un fichier INI, tout contenu précédé par un ; (point virgule) ce n'est qu'à titre informatif, ce n'est pas la directive.
Par contre, je note tout de même ceci : ; Default Value: On
Si c'est réellement à On, alors ce n'est pas correcte, du moins, plus du tout conseillé (à savoir que cette directive n'y saura plus en Php6, ce qui vaudra Off).
Pour savoir la valeur de ta directive, soit tu fais un phpinfo(), soit tu fait un ini_get('magic_quotes_gpc') ou alors prend soin de bien lire ton php.ini et de prendre en compte que les directives non commentées.


Pour ce qui est de tes données en POST pour faire un update, il me semble qu'on a été plusieurs à s'exprimer.
Du coup, je ne vois aucune raison d'en rajouter.
Bref ... c'est toi qui a le bébé en main, alors c'est à toi de voir.

[bond70]

Salut,

Bon je ne t'ai pas dis mais j'utilise Wamp server. Voici un screen du menu des options. L'option magic_quotes_gpc n'est pas coché. Je pense que c'est bon non ?

Sinon je vais faire un traitement dès le $_POST comme tu as dit, c'est pour moi la solution la plus rapide, en plus mon site est en Intranet et ne risque aucune injection SQL ou autre...

Merci

[RunCodePhp]

Bon je ne t'ai pas dis mais j'utilise Wamp server. Voici un screen du menu des options. L'option magic_quotes_gpc n'est pas coché. Je pense que c'est bon non ?

Dans ce cas là ça doit être bon.

[Thes32]

+200000

addslashes n'est pas aussi stricte que mysql_real_escape_string, et surtout, addslashes ne prend pas en compte le jeu de caractères courant de la connexion.

J'ai vu que sur le web beaucoup des gens ont optés pour mysql_escape_string, par contre je ne suis pas convaincu des arguments présentés. ça apporte quoi réellement sur la sécurité ? Je ne vois pas trop non plus l'apport sur le jeu des caractères j'ai bien mes données sauvées via addslashes en utf-8 par exemple.

Contre, également, une généralisation d'une quelconque protection en vue d'éliminer les injections sur toutes les données extérieures (GET/POST/etc) : elles ne sont pas forcément toutes destinées à la base de données et elles doivent être traitées uniquement par rapport à l'usage du moment. On ne traite pas de la même manière les données destinées à une requête (dont on dépend du SGBD d'ailleurs), d'une intégration à une expression régulière (preg_quote), etc.

Si toutes les données entrantes doivent être insérées dans la bdd je ne vois aucun inconvénient (voir le contexte de sa 2de question) et en plus en mon sens je trouve absurde d'échapper les données extérieures tant que l'usage à posteriori n'est susceptible d'une faille de sécurité, etc. sinon on aurait rien fait en désactivant magic_quotes_gpc...

Enfin, je rejoins, une nouvelle fois, RunCodePhp sur l'usage des requêtes préparées qui simplifient bien les choses, et à tous les niveaux (requiert PDO ou MySQLi).

pas du tout contre, je bosse d'ailleurs (presque) toujours avec PDO ou des classes(frameworks, etc..) similaires.

[RunCodePhp]

ça apporte quoi réellement sur la sécurité ? Je ne vois pas trop non plus l'apport sur le jeu des caractères j'ai bien mes données sauvées via addslashes en utf-8 par exemple.

De mon coté je me réfère essentiellement à la Doc ou autre bouquin.
Cependant, comme je l'avais dis, j'avais fais des essais à l'époque quand j'utilisais les fonctions mysql_*, et ces essais démontraient que la fonction mysql_real_escape_string apportait plus que la fonction addslashes.

Concernant la Doc Php, il est dit ceci pour la fonction addslashes
-> http://fr2.php.net/manual/fr/function.addslashes.php

Ces caractères sont les guillemets simples ('), guillemets doubles ("), antislash (\) et NUL (le caractère NULL)

Cela échappe donc que (ou seulement) 4 types de caractères.
Mais il est précisé ceci surtout :

Il est fortement recommandé d'utiliser les fonctions de protection spécifiques à chaque base de données (telle que mysqli_real_escape_string() pour MySQL et pg_escape_string() pour PostGreSQL), mais si la base de données que vous utilisez n'a pas de fonction spécifique, et que cette base utilise \ pour protéger les caractères spéciaux, vous pouvez utiliser cette fonction. Grâce à elle, \ sera ajouté. Si la directive PHP magic_quotes_sybase est activée, ' sera protégé par un autre '.

Donc ce n'est pas moi qui le dit, c'est la communauté Php qui le recommande, et fortement même.


A savoir qu'il y avait la fonction mysql_escape_string qui dans la doc il est précisée quelle est obsolète, donc dépréciée.
C'est la fonction mysql_real_excape_string qui la remplace, qui elle protège plus de caractères que la fonction addslashes.
-> http://fr2.php.net/manual/fr/functio...ape-string.php
Il est précisé ceci :

Note: Si magic_quotes_gpc est activée, appliquez d'abord la fonction stripslashes() à vos données. Utiliser cette fonction sur des données qui ont déjà été protégées, les protégera une deuxième fois.

Pour ma part j'en conclu une chose :
Faire un addslahes revient au même que d'activer la directive magic_quotes_gpc, chose que depuis pas mal de temps la communauté le déconseille fortement. D'ailleurs celle ci devrait ne plus y être dans la version Php6.

Du coup, si on échappe les quotes (magic_quotes_gpc à On ou par addslahes), ci-dessus on conseille de faire un strippslashes(), donc de supprimer les échappements avant d'appliquer un mysql_real_escape_string pour les données en BDD.
Par conséquent, si magic_quotes_gpc à Off, donc désactivé comme c'est le cas de bond70, alors il est quelque part absurde de faire un addslashes.


Avec toutes ces recommandations que fourni la doc, j'en conclu que la fonction addslashes provoquerait très certainement plus de problème quelle n'en résout.
D'ailleurs, cette fonction addslahes n'a apparemment pas la vocation de protéger mais juste échapper, alors que la fonction mysql_real_escape_string elle a pour but de protéger les données pour MySQL.
C'est ce qu'il en ressort il me semble quand je lis la doc.

Donc quelque part, pourquoi vouloir faire autrement ce que recommande la doc ?