Ca ne peut pas avoir de conséquence pour ton serveur (si $champ_de_saisie contient "unlink('toto')", toto ne sera pas supprimé puisque le script n'est
pas interprété).
Alors donc par, les champs de saisie, il n'y a aucun moyen de causer des problèmes au serveur ou à quoi que ce soit d'autre qu'à l'affichage chez le vandale, à moins que je commande à php d'interpréter la saisie comme par ex avec eval(). En fait toute commande à l'interpréteur php qui processerait directement la saisie de données (non filtrée ou autrement) est à éviter.
Donc, la personne qui m'a dit que l'on pouvait causer des problèmes sur un serveur à l'aide d'injections de scripts malicieux dans les champs de saisie est incompétente ou malhonnête. Probablement quelqu'un qui souhaitait que je lui confie l'écriture du site, et pas forcément bénévole !!
Ca ne peut pas avoir de conséquence pour ton serveur (si $champ_de_saisie
contient "unlink('toto')", toto ne sera pas supprimé puisque le script
n'est
pas interprété).
Alors donc par, les champs de saisie, il n'y a aucun moyen de causer des
problèmes au serveur ou à quoi que ce soit d'autre qu'à l'affichage chez le
vandale, à moins que je commande à php d'interpréter la saisie comme par ex
avec eval(). En fait toute commande à l'interpréteur php qui processerait
directement la saisie de données (non filtrée ou autrement) est à éviter.
Donc, la personne qui m'a dit que l'on pouvait causer des problèmes sur un
serveur à l'aide d'injections de scripts malicieux dans les champs de saisie
est incompétente ou malhonnête. Probablement quelqu'un qui souhaitait que je
lui confie l'écriture du site, et pas forcément bénévole !!
Ca ne peut pas avoir de conséquence pour ton serveur (si $champ_de_saisie contient "unlink('toto')", toto ne sera pas supprimé puisque le script n'est
pas interprété).
Alors donc par, les champs de saisie, il n'y a aucun moyen de causer des problèmes au serveur ou à quoi que ce soit d'autre qu'à l'affichage chez le vandale, à moins que je commande à php d'interpréter la saisie comme par ex avec eval(). En fait toute commande à l'interpréteur php qui processerait directement la saisie de données (non filtrée ou autrement) est à éviter.
Donc, la personne qui m'a dit que l'on pouvait causer des problèmes sur un serveur à l'aide d'injections de scripts malicieux dans les champs de saisie est incompétente ou malhonnête. Probablement quelqu'un qui souhaitait que je lui confie l'écriture du site, et pas forcément bénévole !!
Cleo
Pour pouvoir lancer ça à MySQL ? Alors c'est incorrect, on ferait plutôt addslashes($_POST['text']) tout simplement.
Et mysql_escape_string ???
-- Cléo.
Pour pouvoir lancer ça à MySQL ? Alors c'est incorrect, on ferait plutôt
addslashes($_POST['text']) tout simplement.
Pour pouvoir lancer ça à MySQL ? Alors c'est incorrect, on ferait plutôt addslashes($_POST['text']) tout simplement.
Et mysql_escape_string ???
-- Cléo.
N.K. Cole
Il y avait eu, de cela quelques mois maintenant, un post de John Gallet qui avait été fu'd vers un autre newsgroup, je vais voir si je peux le retrouver
<Quelques minutes plus tard>
Voici le sujet en question:
Merci je vais étudier cela.
Il y avait eu, de cela quelques mois maintenant, un post de John Gallet
qui avait été fu'd vers un autre newsgroup, je vais voir si je peux le
retrouver
Il y avait eu, de cela quelques mois maintenant, un post de John Gallet qui avait été fu'd vers un autre newsgroup, je vais voir si je peux le retrouver
<Quelques minutes plus tard>
Voici le sujet en question:
Merci je vais étudier cela.
Sebastian 'CrashandDie' Lauwers
loufoque wrote:
C'est quoi l'intérêt du addslashes ? Pour pouvoir lancer ça à MySQL ? Alors c'est incorrect, on ferait plutôt addslashes($_POST['text']) tout simplement.
??
Un addslashes tout simple vous dites? Alors le problème du js nuisible n'est nullement supprimé...
S.
loufoque wrote:
C'est quoi l'intérêt du addslashes ?
Pour pouvoir lancer ça à MySQL ? Alors c'est incorrect, on ferait plutôt
addslashes($_POST['text']) tout simplement.
??
Un addslashes tout simple vous dites? Alors le problème du js nuisible
n'est nullement supprimé...
C'est quoi l'intérêt du addslashes ? Pour pouvoir lancer ça à MySQL ? Alors c'est incorrect, on ferait plutôt addslashes($_POST['text']) tout simplement.
??
Un addslashes tout simple vous dites? Alors le problème du js nuisible n'est nullement supprimé...
S.
Vincent Lascaux
Alors donc par, les champs de saisie, il n'y a aucun moyen de causer des problèmes au serveur ou à quoi que ce soit d'autre qu'à l'affichage chez le vandale, à moins que je commande à php d'interpréter la saisie comme par ex avec eval(). En fait toute commande à l'interpréteur php qui processerait directement la saisie de données (non filtrée ou autrement) est à éviter.
Oui, tout à fait. Cependant fait attention : il n'y a pas que la commande eval qui peut poser des problemes... Si tu construit une requête SQL à partir d'une variable, cette requête sera interprété par ta base. Si tu construit un chemin de fichier à inclure à partir d'une variable, l'utilisateur pourra peut être inclure des fichiers auquels tu ne pensais pas (par exemple celui qui contient tous les mots de passes).
Donc, la personne qui m'a dit que l'on pouvait causer des problèmes sur un serveur à l'aide d'injections de scripts malicieux dans les champs de saisie est incompétente ou malhonnête. Probablement quelqu'un qui souhaitait que je lui confie l'écriture du site, et pas forcément bénévole !!
Hum... il y a quand même des règles de base à respecter : faire attention quand on construit une requête SQL, ne jamais utiliser une variable non initialisée, demander l'affichage de toutes les erreurs et de tous les avertissements (au moins pendant le développement du site). Mais c'est vrai qu'avec un minimum de rigueur, il n'y a pas trop de risque. Je pense que les principales sources de problèmes sont les evals et les constructions de requêtes SQL.
-- Vincent
Alors donc par, les champs de saisie, il n'y a aucun moyen de causer des
problèmes au serveur ou à quoi que ce soit d'autre qu'à l'affichage chez
le
vandale, à moins que je commande à php d'interpréter la saisie comme par
ex
avec eval(). En fait toute commande à l'interpréteur php qui processerait
directement la saisie de données (non filtrée ou autrement) est à éviter.
Oui, tout à fait. Cependant fait attention : il n'y a pas que la commande
eval qui peut poser des problemes... Si tu construit une requête SQL à
partir d'une variable, cette requête sera interprété par ta base. Si tu
construit un chemin de fichier à inclure à partir d'une variable,
l'utilisateur pourra peut être inclure des fichiers auquels tu ne pensais
pas (par exemple celui qui contient tous les mots de passes).
Donc, la personne qui m'a dit que l'on pouvait causer des problèmes sur un
serveur à l'aide d'injections de scripts malicieux dans les champs de
saisie
est incompétente ou malhonnête. Probablement quelqu'un qui souhaitait que
je
lui confie l'écriture du site, et pas forcément bénévole !!
Hum... il y a quand même des règles de base à respecter : faire attention
quand on construit une requête SQL, ne jamais utiliser une variable non
initialisée, demander l'affichage de toutes les erreurs et de tous les
avertissements (au moins pendant le développement du site).
Mais c'est vrai qu'avec un minimum de rigueur, il n'y a pas trop de risque.
Je pense que les principales sources de problèmes sont les evals et les
constructions de requêtes SQL.
Alors donc par, les champs de saisie, il n'y a aucun moyen de causer des problèmes au serveur ou à quoi que ce soit d'autre qu'à l'affichage chez le vandale, à moins que je commande à php d'interpréter la saisie comme par ex avec eval(). En fait toute commande à l'interpréteur php qui processerait directement la saisie de données (non filtrée ou autrement) est à éviter.
Oui, tout à fait. Cependant fait attention : il n'y a pas que la commande eval qui peut poser des problemes... Si tu construit une requête SQL à partir d'une variable, cette requête sera interprété par ta base. Si tu construit un chemin de fichier à inclure à partir d'une variable, l'utilisateur pourra peut être inclure des fichiers auquels tu ne pensais pas (par exemple celui qui contient tous les mots de passes).
Donc, la personne qui m'a dit que l'on pouvait causer des problèmes sur un serveur à l'aide d'injections de scripts malicieux dans les champs de saisie est incompétente ou malhonnête. Probablement quelqu'un qui souhaitait que je lui confie l'écriture du site, et pas forcément bénévole !!
Hum... il y a quand même des règles de base à respecter : faire attention quand on construit une requête SQL, ne jamais utiliser une variable non initialisée, demander l'affichage de toutes les erreurs et de tous les avertissements (au moins pendant le développement du site). Mais c'est vrai qu'avec un minimum de rigueur, il n'y a pas trop de risque. Je pense que les principales sources de problèmes sont les evals et les constructions de requêtes SQL.
-- Vincent
Vincent Lascaux
C'est quoi l'intérêt du addslashes ? Pour pouvoir lancer ça à MySQL ? Alors c'est incorrect, on ferait plutôt addslashes($_POST['text']) tout simplement.
Un addslashes tout simple vous dites? Alors le problème du js nuisible n'est nullement supprimé...
Pour supprimer le probleme du js nuisible (ou plus généralement pour génerer une chaine qui s'affichera comme l'utilisateur l'a entrée), il ne faut pas utiliser addslashes mais htmlentities (et nl2br eventuellement). Pour fabriquer une requete SQL à partir du texte que l'utilisateur a entré, il ne faut pas utiliser htmlentities mais addslashes (ou plutot mysql_escape_string ?)
Je ne comprends pas (tout comme loufoque) l'interet d'utiliser les deux. Ce n'est pas en accumulant les fonctions que tu rends ton site plus sur, mais en utilisant les bonnes fonctions au bon endroit.
-- Vincent
C'est quoi l'intérêt du addslashes ?
Pour pouvoir lancer ça à MySQL ? Alors c'est incorrect, on ferait plutôt
addslashes($_POST['text']) tout simplement.
Un addslashes tout simple vous dites? Alors le problème du js nuisible
n'est nullement supprimé...
Pour supprimer le probleme du js nuisible (ou plus généralement pour génerer
une chaine qui s'affichera comme l'utilisateur l'a entrée), il ne faut pas
utiliser addslashes mais htmlentities (et nl2br eventuellement).
Pour fabriquer une requete SQL à partir du texte que l'utilisateur a entré,
il ne faut pas utiliser htmlentities mais addslashes (ou plutot
mysql_escape_string ?)
Je ne comprends pas (tout comme loufoque) l'interet d'utiliser les deux. Ce
n'est pas en accumulant les fonctions que tu rends ton site plus sur, mais
en utilisant les bonnes fonctions au bon endroit.
C'est quoi l'intérêt du addslashes ? Pour pouvoir lancer ça à MySQL ? Alors c'est incorrect, on ferait plutôt addslashes($_POST['text']) tout simplement.
Un addslashes tout simple vous dites? Alors le problème du js nuisible n'est nullement supprimé...
Pour supprimer le probleme du js nuisible (ou plus généralement pour génerer une chaine qui s'affichera comme l'utilisateur l'a entrée), il ne faut pas utiliser addslashes mais htmlentities (et nl2br eventuellement). Pour fabriquer une requete SQL à partir du texte que l'utilisateur a entré, il ne faut pas utiliser htmlentities mais addslashes (ou plutot mysql_escape_string ?)
Je ne comprends pas (tout comme loufoque) l'interet d'utiliser les deux. Ce n'est pas en accumulant les fonctions que tu rends ton site plus sur, mais en utilisant les bonnes fonctions au bon endroit.
-- Vincent
Cleo
Bonjour, Je vais tenté de résumer le problème. Pour schématiser, il y a deux types d'entrée/sortie, le premier c'est l'interface HTML (entrée: variables GPC, sortie: flux HMTL), le second c'est le système de stockage (BDD ou Fichier).
Schema: HTML <-A-> Script PHP <-B-> Stockage
Le script php doit donc jouer un rôle de traducteur.
Sur les entrées A et B du script, PHP offre une pseudo fonctionnalité appelée magic_quotes consistant à backslasher les quotes pour plus de simplicité d'écriture ou de manipulation. Deux fonctions sont disponibles pour tester l'activation de magic_quotes sur les entrées A et B, respectivement get_magic_quotes_gpc() et get_magic_quotes_runtime(). Le mieux, je pense, est de s'en passer pour rester claire, l'objectif étant, dans le script, de manipuler que des chaines chaines "propres" (non slashées).
Le principe de manipulation des chaines est donc le suivant: 1- de HTML vers SCRIPT Les chaines reçues via (_GET, _POST, _COOKIES) doivent être traitées par stripslashes si get_magic_quotes_gpc() == true.
2- de SCRIPT vers HTML 2.1) Les chaines écrites comme texte (hors attribut HTML et TEXTAREA) doivent subir htmlentities( ... ,ENT_NOQUOTES) et nl2br(). 2.2) Les chaines écrites comme attribut d'une balise html (entre double quote) [ex: value="..."] doivent subir htmlentities( ... , ENT_COMPAT), les sauts de ligne n'étant pas acceptés. 2.3) Les chaines écrites comme attribut d'une balise html à l'intérieur d'un script [ex: onclick="alert('...')"] doivent subir htmlentities( ... , ENT_QUOTES), les sauts de ligne n'étant pas acceptés. 2.4) Les chaines écrites comme contenu d'un TEXTAREA, doivent être traitées par htmlentities( ... , ENT_NOQUOTES) MAIS PAS nl2br !!
3- de Stockage vers SCRIPT. Les chaines reçues de la base, ou d'un fichier text doivent être traitées par stripslashes si get_magic_quotes_runtime() == true.
4- de SCRIPT vers Stockage. pour les fichiers RAS. pour la base, il est nécessaire d'utiliser les fonctions d'échappement fournies avec le driveur base: mysql_escape_string, pg_escape_string ... pour écrire les requêtes [ex: where value='..'].
Je pense avoir fait le tour des cas d'utilisation. Fi des injections :) ... au suivant ... -- Cléo.
Bonjour,
Je vais tenté de résumer le problème.
Pour schématiser, il y a deux types d'entrée/sortie, le premier c'est
l'interface HTML (entrée: variables GPC, sortie: flux HMTL), le second c'est
le système de stockage (BDD ou Fichier).
Schema:
HTML <-A-> Script PHP <-B-> Stockage
Le script php doit donc jouer un rôle de traducteur.
Sur les entrées A et B du script, PHP offre une pseudo fonctionnalité
appelée magic_quotes consistant à backslasher les quotes pour plus de
simplicité d'écriture ou de manipulation. Deux fonctions sont disponibles
pour tester l'activation de magic_quotes sur les entrées A et B,
respectivement get_magic_quotes_gpc() et get_magic_quotes_runtime(). Le
mieux, je pense, est de s'en passer pour rester claire, l'objectif étant,
dans le script, de manipuler que des chaines chaines "propres" (non
slashées).
Le principe de manipulation des chaines est donc le suivant:
1- de HTML vers SCRIPT
Les chaines reçues via (_GET, _POST, _COOKIES) doivent être traitées par
stripslashes si get_magic_quotes_gpc() == true.
2- de SCRIPT vers HTML
2.1) Les chaines écrites comme texte (hors attribut HTML et TEXTAREA)
doivent subir htmlentities( ... ,ENT_NOQUOTES) et nl2br().
2.2) Les chaines écrites comme attribut d'une balise html (entre double
quote) [ex: value="..."] doivent subir htmlentities( ... , ENT_COMPAT), les
sauts de ligne n'étant pas acceptés.
2.3) Les chaines écrites comme attribut d'une balise html à l'intérieur d'un
script [ex: onclick="alert('...')"] doivent subir htmlentities( ... ,
ENT_QUOTES), les sauts de ligne n'étant pas acceptés.
2.4) Les chaines écrites comme contenu d'un TEXTAREA, doivent être traitées
par htmlentities( ... , ENT_NOQUOTES) MAIS PAS nl2br !!
3- de Stockage vers SCRIPT.
Les chaines reçues de la base, ou d'un fichier text doivent être traitées
par stripslashes si get_magic_quotes_runtime() == true.
4- de SCRIPT vers Stockage.
pour les fichiers RAS.
pour la base, il est nécessaire d'utiliser les fonctions d'échappement
fournies avec le driveur base: mysql_escape_string, pg_escape_string ...
pour écrire les requêtes [ex: where value='..'].
Je pense avoir fait le tour des cas d'utilisation. Fi des injections :) ...
au suivant ...
--
Cléo.
Bonjour, Je vais tenté de résumer le problème. Pour schématiser, il y a deux types d'entrée/sortie, le premier c'est l'interface HTML (entrée: variables GPC, sortie: flux HMTL), le second c'est le système de stockage (BDD ou Fichier).
Schema: HTML <-A-> Script PHP <-B-> Stockage
Le script php doit donc jouer un rôle de traducteur.
Sur les entrées A et B du script, PHP offre une pseudo fonctionnalité appelée magic_quotes consistant à backslasher les quotes pour plus de simplicité d'écriture ou de manipulation. Deux fonctions sont disponibles pour tester l'activation de magic_quotes sur les entrées A et B, respectivement get_magic_quotes_gpc() et get_magic_quotes_runtime(). Le mieux, je pense, est de s'en passer pour rester claire, l'objectif étant, dans le script, de manipuler que des chaines chaines "propres" (non slashées).
Le principe de manipulation des chaines est donc le suivant: 1- de HTML vers SCRIPT Les chaines reçues via (_GET, _POST, _COOKIES) doivent être traitées par stripslashes si get_magic_quotes_gpc() == true.
2- de SCRIPT vers HTML 2.1) Les chaines écrites comme texte (hors attribut HTML et TEXTAREA) doivent subir htmlentities( ... ,ENT_NOQUOTES) et nl2br(). 2.2) Les chaines écrites comme attribut d'une balise html (entre double quote) [ex: value="..."] doivent subir htmlentities( ... , ENT_COMPAT), les sauts de ligne n'étant pas acceptés. 2.3) Les chaines écrites comme attribut d'une balise html à l'intérieur d'un script [ex: onclick="alert('...')"] doivent subir htmlentities( ... , ENT_QUOTES), les sauts de ligne n'étant pas acceptés. 2.4) Les chaines écrites comme contenu d'un TEXTAREA, doivent être traitées par htmlentities( ... , ENT_NOQUOTES) MAIS PAS nl2br !!
3- de Stockage vers SCRIPT. Les chaines reçues de la base, ou d'un fichier text doivent être traitées par stripslashes si get_magic_quotes_runtime() == true.
4- de SCRIPT vers Stockage. pour les fichiers RAS. pour la base, il est nécessaire d'utiliser les fonctions d'échappement fournies avec le driveur base: mysql_escape_string, pg_escape_string ... pour écrire les requêtes [ex: where value='..'].
Je pense avoir fait le tour des cas d'utilisation. Fi des injections :) ... au suivant ... -- Cléo.
Cleo
Je vais tenté de résumer le problème. ... TENTER ...
Pardon, honte sur moi ! ...
-- Cléo.
Je vais tenté de résumer le problème.
... TENTER ...
Je vais tenté de résumer le problème. ... TENTER ...
Pardon, honte sur moi ! ...
-- Cléo.
N.K. Cole
eval qui peut poser des problemes... Si tu construit une requête SQL à partir d'une variable, cette requête sera interprété par ta base. Si tu construit un chemin de fichier à inclure à partir d'une variable, l'utilisateur pourra peut être inclure des fichiers auquels tu ne pensais pas (par exemple celui qui contient tous les mots de passes).
Donc on en revient au filtrage de champ de saisie. A moins qu'il existe des fonctions permettant de détecter cela.
Par ex. si dans un formulaire je receuille le nom dans $nom et que ma requete d'insertion est (engros) $req = "insert into visiteurs values(....,$nom) mysqli_execute($req)
je risque gros. Mais si je filtre $nom !?!?
eval qui peut poser des problemes... Si tu construit une requête SQL à
partir d'une variable, cette requête sera interprété par ta base. Si tu
construit un chemin de fichier à inclure à partir d'une variable,
l'utilisateur pourra peut être inclure des fichiers auquels tu ne pensais
pas (par exemple celui qui contient tous les mots de passes).
Donc on en revient au filtrage de champ de saisie. A moins qu'il existe des
fonctions permettant de détecter cela.
Par ex. si dans un formulaire je receuille le nom dans $nom et que ma
requete d'insertion est (engros)
$req = "insert into visiteurs values(....,$nom)
mysqli_execute($req)
eval qui peut poser des problemes... Si tu construit une requête SQL à partir d'une variable, cette requête sera interprété par ta base. Si tu construit un chemin de fichier à inclure à partir d'une variable, l'utilisateur pourra peut être inclure des fichiers auquels tu ne pensais pas (par exemple celui qui contient tous les mots de passes).
Donc on en revient au filtrage de champ de saisie. A moins qu'il existe des fonctions permettant de détecter cela.
Par ex. si dans un formulaire je receuille le nom dans $nom et que ma requete d'insertion est (engros) $req = "insert into visiteurs values(....,$nom) mysqli_execute($req)
je risque gros. Mais si je filtre $nom !?!?
Vincent Lascaux
Par ex. si dans un formulaire je receuille le nom dans $nom et que ma requete d'insertion est (engros) $req = "insert into visiteurs values(....,$nom) mysqli_execute($req)
je risque gros.
oui... Certaines bases de données permettent l'execution de plusieurs requetes séparées par un point virgule. L'utilisateur entre pour valeur de $nom Machin') ; DELETE from visiteurs WHERE ('A'='A
Toi tu construis ta requete "insert into visiteurs value (12, 42, '$nom')" pensant que c'est tout bon. En remplacant $nom, ca donne insert into visiteurs value (12, 42, 'Machin') ; DELETE from visiteurs WHERE ('A'='A') et ca te vide ta base
Même si ta base n'execute qu'une requete à la fois, ca peut être problématique. J'ai déjà vu des systeme de login / mot de passe où le login magique ' OR 1 OR ' marche à tous les coups (parceque la requête est "WHERE Name = '$name' AND Password = MD5('$password')"). Ca fait pas très propre de laisser n'importe qui se logger... Avec un peu de chance, il est dans le même genre possible de changer une requête SQL pour récuperer l'intégralité des mots de passes...
L'idée c'est de préfixer les ' par des (et d'autres subtilités) mysql_escape_string est faite pour ca
Mais si je filtre $nom !?!?
Ca dépend ce que tu entends par filtrer... Une simple validation n'est pas suffisante, il faut de toutes façons changer la valeur du nom même si l'utilisateur ne cherchait pas à nuir. Si D'Artagnan vient sur ton site, ca ne marchera pas non plus... il faut mettre D'Artagnan dans la requête SQL (et pas trop compter sur le mousquetaire pour le faire à ta place)
-- Vincent
Par ex. si dans un formulaire je receuille le nom dans $nom et que ma
requete d'insertion est (engros)
$req = "insert into visiteurs values(....,$nom)
mysqli_execute($req)
je risque gros.
oui...
Certaines bases de données permettent l'execution de plusieurs requetes
séparées par un point virgule. L'utilisateur entre pour valeur de $nom
Machin') ; DELETE from visiteurs WHERE ('A'='A
Toi tu construis ta requete "insert into visiteurs value (12, 42, '$nom')"
pensant que c'est tout bon.
En remplacant $nom, ca donne
insert into visiteurs value (12, 42, 'Machin') ; DELETE from visiteurs WHERE
('A'='A') et ca te vide ta base
Même si ta base n'execute qu'une requete à la fois, ca peut être
problématique. J'ai déjà vu des systeme de login / mot de passe où le login
magique ' OR 1 OR ' marche à tous les coups (parceque la requête est "WHERE
Name = '$name' AND Password = MD5('$password')"). Ca fait pas très propre de
laisser n'importe qui se logger... Avec un peu de chance, il est dans le
même genre possible de changer une requête SQL pour récuperer l'intégralité
des mots de passes...
L'idée c'est de préfixer les ' par des (et d'autres subtilités)
mysql_escape_string est faite pour ca
Mais si je filtre $nom !?!?
Ca dépend ce que tu entends par filtrer... Une simple validation n'est pas
suffisante, il faut de toutes façons changer la valeur du nom même si
l'utilisateur ne cherchait pas à nuir.
Si D'Artagnan vient sur ton site, ca ne marchera pas non plus... il faut
mettre D'Artagnan dans la requête SQL (et pas trop compter sur le
mousquetaire pour le faire à ta place)
Par ex. si dans un formulaire je receuille le nom dans $nom et que ma requete d'insertion est (engros) $req = "insert into visiteurs values(....,$nom) mysqli_execute($req)
je risque gros.
oui... Certaines bases de données permettent l'execution de plusieurs requetes séparées par un point virgule. L'utilisateur entre pour valeur de $nom Machin') ; DELETE from visiteurs WHERE ('A'='A
Toi tu construis ta requete "insert into visiteurs value (12, 42, '$nom')" pensant que c'est tout bon. En remplacant $nom, ca donne insert into visiteurs value (12, 42, 'Machin') ; DELETE from visiteurs WHERE ('A'='A') et ca te vide ta base
Même si ta base n'execute qu'une requete à la fois, ca peut être problématique. J'ai déjà vu des systeme de login / mot de passe où le login magique ' OR 1 OR ' marche à tous les coups (parceque la requête est "WHERE Name = '$name' AND Password = MD5('$password')"). Ca fait pas très propre de laisser n'importe qui se logger... Avec un peu de chance, il est dans le même genre possible de changer une requête SQL pour récuperer l'intégralité des mots de passes...
L'idée c'est de préfixer les ' par des (et d'autres subtilités) mysql_escape_string est faite pour ca
Mais si je filtre $nom !?!?
Ca dépend ce que tu entends par filtrer... Une simple validation n'est pas suffisante, il faut de toutes façons changer la valeur du nom même si l'utilisateur ne cherchait pas à nuir. Si D'Artagnan vient sur ton site, ca ne marchera pas non plus... il faut mettre D'Artagnan dans la requête SQL (et pas trop compter sur le mousquetaire pour le faire à ta place)
