Discussion :

[psychoBob]

Peut être, oui, je vais vérifier.

Mais la question m'intéresse toujours : Pour la sécurité, doit-on obligatoirement filtrer le contenu d'une variable dès sa réception ou peut-on exécuter des fonctions dessus avant de la filtrer ?

[ePoX]

Pour la sécurité, doit-on obligatoirement filtrer le contenu d'une variable dès sa réception ou peut-on exécuter des fonctions dessus avant de la filtrer ?

La question est plutot : Qu'est ce que je désire sauvegarder dans ma bdd pour m'en reservir plus tard.

La protection des donnée devrait logiquement n'intervenir qu'en dernier dans la chaine, puisque ce n'est pas lui qui vas définir ce que tu insère, il est juste la pour s'assurer que tout se passe correctement.

OU ALORS

Si tu executes mysql_resl_escape_string avant d'executer des fonctions X , Y dessus qui te dit qu'à la sortie de tes fonctions X, Y ta chaine ne sera pas devenu un danger public ?

Mais ceci dit je me demande si je réponds pas à coté... Par ce que tu parles de sécurité alors que deux post plus haut tu parlais de htmlentites... Il y aurait il un rapport que je n'aurais pas su déceler ?

[psychoBob]

Mais ceci dit je me demande si je réponds pas à coté... Par ce que tu parles de sécurité alors que deux post plus haut tu parlais de htmlentites... Il y aurait il un rapport que je n'aurais pas su déceler ?

Extraordinaire fin de post, car je me suis dit cela tout long de la lecture de ta réponse, intéressante au demeurant

En fait ce sont des questions de débutants qui veulent comprendre à tout prix mais sans méthode... ça colle un peu des fois.

Si tu executes mysql_resl_escape_string avant d'executer des fonctions X , Y dessus qui te dit qu'à la sortie de tes fonctions X, Y ta chaine ne sera pas devenu un danger public ?

Ce point là est intéressant. Tu veux dire qu'en appliquant une fonction censée assurer la sécurité avec des slashes par exemple, alors on risque en appliquant juste après une fonction x ou y sans rapport avec la sécurité, de déclencher un bug, voir une faille.
C'est pas de bol quand même.

Personnellement je me dis l'inverse : si on applique une fonction x ou y sans rapport avec la sécurité sur une variable contenant un script douteux non filtré, alors là on risque là catastrophe, donc mieux vaut la filtrer avant.

[ePoX]

C'est pas de bol quand même.

ah c'est sur... Mais c'était juste histoire d'illustrer...

Citation:
Si tu executes mysql_resl_escape_string avant d'executer des fonctions X , Y dessus qui te dit qu'à la sortie de tes fonctions X, Y ta chaine ne sera pas devenu un danger public ?


Ce point là est intéressant. Tu veux dire qu'en appliquant une fonction censée assurer la sécurité avec des slashes par exemple, alors on risque en appliquant juste après une fonction x ou y sans rapport avec la sécurité, de déclencher un bug, voir une faille.
C'est pas de bol quand même.

Personnellement je me dis l'inverse :

Supposons,

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
function addquote( $var )
{
return  $var." ' ";
}
 
$a = "a"; 
 
$a = mysql_real_escape_string($a);
 
$a = addquote($a);
 
$sql = "SELECT truc FROM bidule WHERE bdc = ' ".$a." ' ";
mysq_query($sql);

Sa sert à quoi d'avoir fait le mysql_real_escape_string la ??? rien.

si on applique une fonction x ou y sans rapport avec la sécurité sur une variable contenant un script douteux non filtré, alors là on risque là catastrophe, donc mieux vaut la filtrer avant.

[weed]

"considéré come du texte simple"... pour qui ? pour quoi ? qu'entends tu par "simple" ?

avec le magic_quotes_gpc activé, lorsque tu envoies les données transmises en POST, GET et via des cookies à Apache, juste avant quelle soit traitées des \ sont ajoutés à des doubles quotes et simples quotes.


Par exemple sans faire trop gaffe, j'envoie
http://www.developpez.net/forums/login.php comme donnée en post :
username = "Mr N"#"
password = "je men fou"
autologin = "on"
redirect = ""

si le magic quote n'est pas activé, je peux esperer me connecter sans connaitre le mot de passe.

Code :

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

$query = "SELECT * FROM users WHERE login = Mr N

par inavertance, j'ai ajouté un # ce qui fait que tout ce qui suit apres la verification du login est ignorée.

alors que si les magic quote activé, des antislahes seront ajoutés juste avant les " : \"Mr N\"#\" et donc et donc Mr N"# sera considéré comme une chaine. Le # n'est plus considéré comme une commande SQL.

Et donc si j'envoie mes données à login.php avec le magic quotes activé, je suis foutu. La verification apres le login ne peut plus etre ignorée.

Code :

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

$query = "SELECT * FROM users WHERE login = "Mr N\"#" AND password = "je men fou"

donc voilou. Tout ce que l'on enverra en post, en get ou cookies sera considéré comme du texte simple donc inoffensif.

[psychoBob]

Oui mais c'est idiot ton truc on va pas addquoter une variable après l'avoir mysql_real_escape_stringer le tout avant de l'insérer dans la base.

Dans mon exemple on insérait rien dans la base, htmlentities tournait coté serveur, pour afficher la prévisualisation du message du formulaire. Donc on s'en fiche des requêtes sql là, on utilise que htmlentities.

Puis avant l'insertion, là on utilise mysql_real_real_string.

**edit**
on a posté en même temps, ma réponse s'adresse à ePoX.

[ePoX]

Oui mais c'est idiot ton truc on va pas addquoter une variable après l'avoir mysql_real_escape_stringer le tout avant de l'insérer dans la base.

Mais je sais que c'est bete.... mais pourquoi prendre un truc compliqué quand c'est juste une illustration

Dans mon exemple on insérait rien dans la base, htmlentities tournait coté serveur, pour afficher la prévisualisation du message du formulaire. Donc on s'en fiche des requêtes sql là, on utilise que htmlentities.

Ben c'est quoi le rapport avec la sécurité

cf :

Pour la sécurité, doit-on obligatoirement filtrer le contenu d'une variable dès sa réception ou peut-on exécuter des fonctions dessus avant de la filtrer ?

Puis avant l'insertion, là on utilise mysql_real_real_string.

De toute facon c'est bien cela qu'i fallait retenir.

[psychoBob]

Ah oui mais p on a besoin d'htmlentities pour filtrer les données du formulaire avant de les afficher sur la page dans l'espace de prévisualisation: Cela contre les injections XSS (tention j'ai appris ma leçon 8) )

Puis au moment de la validation, c'est mysql_real_escape_string (je vais le connaître par coeur).

C'est ça le rapport avec la sécurité.

[vg33]

Ah oui mais p on a besoin d'htmlentities pour filtrer les données du formulaire avant de les afficher sur la page dans l'espace de prévisualisation: Cela contre les injections XSS (tention j'ai appris ma leçon 8) )

Puis au moment de la validation, c'est mysql_real_escape_string (je vais le connaître par coeur).

C'est ça le rapport avec la sécurité.

+1 (j'aurais pas dit mieux)

[psychoBob]

En fait j'ai un problème maintenant :

Avant l'insertion dans la base j'utilise donc mysql_real_escape_string, mais maintenant à l'affichage j'obtiens, par exemple :

l///'Allemagne c///'est génial.

Et ça résiste au stripslashes ces petites bêtes la.

Comment je les éradique ?

[weed]

le mysql_real_escape_string est peut etre sympa, mais avec le magic quote activé, c'est un peu inutile.

[Mr N.]

le mysql_real_escape_string est peut etre sympa, mais avec le magic quote activé, c'est un peu inutile.

C'est pas inutile, c'est qu'il faut faire un stripslashes avant.

[Kioob]

j'ai un peu l'impression qu'on se répète depuis 5 pages...

Mr N a pourtant bien résumé :
- magic_quotes_gpc fait la même chose que addslashes.
- addslashes ne fait absoluement pas la même chose que mysql_real_escape_string

La solution ? Comme indiqué dans la doc, quand cette saloperie de magic_quotes_gpc est activé il faut d'abord faire un stripslashes() avant de faire le mysql_real_escape_string().

[Anduriel]

Désolé pour le retard.
Alors voila j'utilise (même si ça dérive du sujet) mysql_real_escape_string mais j'ai une erreur de syntaxe depuis ce cette utilisation.
Voila ce que je fais:

Code :

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

1
2
3
4
$Pseudo = quote_smart(trim($_POST['Pseudo']));
$Titre = quote_smart(trim($_POST['Titre']));
$Message = quote_smart(trim($_POST['Texte']));
$connect->query("INSERT INTO ".$db['prefix']."_msg VALUES('', '".$Titre."', '".$Pseudo."', '".$Email."', '".$_SERVER['REMOTE_ADDR']."', '".$Url."', '".date_fr()."', '".$Message."')");

Et la fonction quote_smart() est celle du livre.
Ou est l'erreur?
Merci

[ePoX]

Elle est ou l'erreur ?

[Anduriel]

Bein justement j'ai ça:

Erreur de syntaxe près de 'Titre'', ''Anduriel'', 'anduriel@anduriel.fr', '127.0.0.1', 'http:/' à la ligne 1

[ePoX]

ta fonction quote_smart ressemble execute cela ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
// Protège la variable
function quote_smart($value)
{
   // Stripslashes
   if (get_magic_quotes_gpc()) {
     $value = stripslashes($value);
   }
   // Protection si ce n'est pas un entier
   if (!is_numeric($value)) {
     $value = "'" . mysql_real_escape_string($value) . "'";
   }
   return $value;
}

Juste avant la création de la requete, tu as essayé un var_dump($Pseudo) ?

[Mr N.]

Bien vu ePox, je pense que tu n'as pas besoin de mettre de quotes pour les values dans la construction de ta requète Anduriel.

[Anduriel]

Bien vu ePox, je pense que tu n'as pas besoin de mettre de quotes pour les values dans la construction de ta requète Anduriel.

Comment ça?

[Mr N.]

Code :

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

$connect->query("INSERT INTO ".$db['prefix']."_msg VALUES('', ".$Titre.", ".$Pseudo.", ".$Email.", '".$_SERVER['REMOTE_ADDR']."', ".$Url.", '".date_fr()."', ".$Message.")");

Bref, là où tu te sers de quote_smart, tu n'as pas à mettre de quotes.

Sinon je te conseilles d'indiquer les colonnes dans ta requette d'insertion...