Insertion de simples cote dans une table

Version imprimable

02/07/2010, 11h23
bond70

Insertion de simples cote dans une table

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 !!!:ccool:

salut,

tu dois utiliser la fonction addslashes
Code:

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

02/07/2010, 11h34
bond70

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

exemple ici :

Citation:

SET texteChamp1='$texte'

merci!
02/07/2010, 11h38
Thes32

peux tu montrer un peu plus de code ?

Code:

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 :

Citation:

SET texteObservation='$obs1'

Erreur :

Citation:

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

Code:

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());

02/07/2010, 11h45
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!!

Re :D

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

Exemple :
Code:

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 :

Citation:

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

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

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 );

02/07/2010, 11h58
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 ?
02/07/2010, 11h59
Thes32

@RunCodePhp : mysql_real_escape_string() consomme beaucoup plus des ressources que addslashes et nécessite une connexion mysql soit ouverte.
02/07/2010, 12h04
Thes32

Citation:

Envoyé par RunCodePhp

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 ?

Citation:

Envoyé par RunCodePhp

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 ?

Citation:

Envoyé par RunCodePhp

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.
02/07/2010, 12h10
RunCodePhp

Citation:

Envoyé par Thes32

@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. ;)

Citation:

Envoyé par Thes32

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. ;)
02/07/2010, 12h16
julp

Citation:

Envoyé par RunCodePhp

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).
02/07/2010, 13h45
bond70

Salut à tous,

Je vois que ma question porte à débat.:lol:

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

Citation:

; 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 !
02/07/2010, 14h36
RunCodePhp

Citation:

; 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. ;)
02/07/2010, 15h33
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 :ccool:
04/07/2010, 08h45
RunCodePhp

Citation:

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. ;)
05/07/2010, 13h31
Thes32

Citation:

Envoyé par julp

+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.

Citation:

Envoyé par julp

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...

Citation:

Envoyé par julp

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.
05/07/2010, 19h16
RunCodePhp

Citation:

Envoyé par Thes32

ç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

Citation:

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 :

Citation:

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 :

Citation:

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 ?
05/07/2010, 19h45
julp

Citation:

Envoyé par Thes32

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.

Citation:

Security Fix: An SQL-injection security hole has been found in multi-byte encoding processing. The bug was in the server, incorrectly parsing the string escaped with the mysql_real_escape_string() C API function.

This vulnerability was discovered and reported by Josh Berkus <josh@postgresql.org> and Tom Lane <tgl@sss.pgh.pa.us> as part of the inter-project security collaboration of the OSDB consortium. For more information about SQL injection, please see the following text.

Discussion. An SQL injection security hole has been found in multi-byte encoding processing. An SQL injection security hole can include a situation whereby when a user supplied data to be inserted into a database, the user might inject SQL statements into the data that the server will execute. With regards to this vulnerability, when character set-unaware escaping is used (for example, addslashes() in PHP), it is possible to bypass the escaping in some multi-byte character sets (for example, SJIS, BIG5 and GBK). As a result, a function such as addslashes() is not able to prevent SQL-injection attacks. It is impossible to fix this on the server side. The best solution is for applications to use character set-aware escaping offered by a function such mysql_real_escape_string().

(source : annonces des versions 5.0.22 et 5.1.11)

D'ailleurs, la version 5.0.1 de MySQL a vu l'introduction du mode d'échappement NO_BACKSLASH_ESCAPES (apostrophes doublées, le backslash perdant son caractère spécial d'échappement) que seul mysql_real_escape_string ne peut réellement honorer.

(pour rappel, mysql_escape_string est similaire à addslashes : elle ne dépend pas de la connexion donc de ses "paramètres", ce qui lui vaut, à juste titre, cette dépréciation)

Citation:

Envoyé par Thes32

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)

En ce cas ce serait acceptable. Mais, ça reste, selon moi, une mauvaise pratique et surtout une habitude à ne surtout pas prendre.