Lorsque un utilisateur s'inscrit sur mon site, et qu'il a saisie des ","
dans son adresse (ou autre champ), cela cause une erreur SQL.
exemple de requete SQL:
$SQL="INSERT INTO tb_user ('','$_POST[nom]','$_POST['adresse']')";
Si $_POST['adresse'] = "6, rue blabla" cela donne la requete SQL suivante :
$SQL="INSERT INTO tb_user ('','moi','6, rue blabla')";
La "," aprés le 6 cause une erreur de requete.
Existe t il un moyen simple pour accepter les "," dans un champ SQL,
mis à part un str_replace(","," ",$_POST['adresse'])
On peut faire une injection SQL sans utiliser le '
[..]
$query = 'SELECT * FROM table WHERE id=''.mysql_real_escape_string( $_POST['password'] ).''';
Nécessaire et suffisant.
Sauf que les apostrophes c'est pour les chaines de caractère et que mon id là supposé être un entier, donc une requête SQL écrite correctement n'aura pas d'apostrophes. Je répète donc: on peut faire une injection SQL sans ' et la solution à ces problèmes n'est PAS l'appel à des fonctions de protection des caractères dangereux (en tout cas PAS SEULEMENT).
Ceux qui croient qu'on résout tous les problèmes de sécurité avec addslashes ou équivalent n'ont rien compris au problème qu'ils essayent de résoudre.
Et, au passage, question portabilité (d'un SGBDR à un autre), votre code pose problème.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
On peut faire une injection SQL sans utiliser le '
[..]
$query = 'SELECT * FROM table WHERE id=''.mysql_real_escape_string(
$_POST['password'] ).''';
Nécessaire et suffisant.
Sauf que les apostrophes c'est pour les chaines de caractère et
que mon id là supposé être un entier, donc une requête SQL écrite correctement
n'aura pas d'apostrophes.
Je répète donc: on peut faire une injection SQL sans ' et la solution à
ces problèmes n'est PAS l'appel à des fonctions de protection des
caractères dangereux (en tout cas PAS SEULEMENT).
Ceux qui croient qu'on résout tous les problèmes de sécurité avec
addslashes ou équivalent n'ont rien compris au problème qu'ils essayent
de résoudre.
Et, au passage, question portabilité (d'un SGBDR à un autre), votre code
pose problème.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
On peut faire une injection SQL sans utiliser le '
[..]
$query = 'SELECT * FROM table WHERE id=''.mysql_real_escape_string( $_POST['password'] ).''';
Nécessaire et suffisant.
Sauf que les apostrophes c'est pour les chaines de caractère et que mon id là supposé être un entier, donc une requête SQL écrite correctement n'aura pas d'apostrophes. Je répète donc: on peut faire une injection SQL sans ' et la solution à ces problèmes n'est PAS l'appel à des fonctions de protection des caractères dangereux (en tout cas PAS SEULEMENT).
Ceux qui croient qu'on résout tous les problèmes de sécurité avec addslashes ou équivalent n'ont rien compris au problème qu'ils essayent de résoudre.
Et, au passage, question portabilité (d'un SGBDR à un autre), votre code pose problème.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
ftc
$query = 'SELECT * FROM table WHERE id=''.mysql_real_escape_string( $_POST['password'] ).''';
Nécessaire et suffisant.
Sauf que les apostrophes c'est pour les chaines de caractère et que mon id là supposé être un entier, donc une requête SQL écrite correctement n'aura pas d'apostrophes.
Cette requête est correcte puisque MySQL l'exécute comme attendu. Si je me souviens bien ce qui est dit dans la norme SQL92 c'est que les valeurs numériques n'ont pas besoin de quote pas qu'elles ne doivent pas en avoir.
Le seul problème qui puisse se poser est lorsque la variable vaut NULL, ce qui est quand même extrêmement rare pour des données entrées par l'utilisateur.
Après, si on veut aller plus loin, on peut écrire des fonctions qui détermine si le champs doit être numérique ou non et ensuite tester si la variable est numérique ou non.
Le mieux étant d'avoir un SGBD qui supporte les requêtes préparées, on peut alors s'affranchir de la plupart des vérifications.
[SNIP]
Et, au passage, question portabilité (d'un SGBDR à un autre), votre code pose problème.
Si j'ai utiliser MySQL, c'est pour l'exemple.
Si on veut la portabilité, on utilise une couche d'abstraction qui pour la plupart ont leur fonction d'échappement qui ensuite fait appel à celle de mysql ou postgresql ... donc, là n'est pas le propos.
$query = 'SELECT * FROM table WHERE id=''.mysql_real_escape_string(
$_POST['password'] ).''';
Nécessaire et suffisant.
Sauf que les apostrophes c'est pour les chaines de caractère et
que mon id là supposé être un entier, donc une requête SQL écrite correctement
n'aura pas d'apostrophes.
Cette requête est correcte puisque MySQL l'exécute comme attendu. Si je
me souviens bien ce qui est dit dans la norme SQL92 c'est que les
valeurs numériques n'ont pas besoin de quote pas qu'elles ne doivent pas
en avoir.
Le seul problème qui puisse se poser est lorsque la variable vaut NULL,
ce qui est quand même extrêmement rare pour des données entrées par
l'utilisateur.
Après, si on veut aller plus loin, on peut écrire des fonctions qui
détermine si le champs doit être numérique ou non et ensuite tester si
la variable est numérique ou non.
Le mieux étant d'avoir un SGBD qui supporte les requêtes préparées, on
peut alors s'affranchir de la plupart des vérifications.
[SNIP]
Et, au passage, question portabilité (d'un SGBDR à un autre), votre code
pose problème.
Si j'ai utiliser MySQL, c'est pour l'exemple.
Si on veut la portabilité, on utilise une couche d'abstraction qui pour
la plupart ont leur fonction d'échappement qui ensuite fait appel à
celle de mysql ou postgresql ... donc, là n'est pas le propos.
$query = 'SELECT * FROM table WHERE id=''.mysql_real_escape_string( $_POST['password'] ).''';
Nécessaire et suffisant.
Sauf que les apostrophes c'est pour les chaines de caractère et que mon id là supposé être un entier, donc une requête SQL écrite correctement n'aura pas d'apostrophes.
Cette requête est correcte puisque MySQL l'exécute comme attendu. Si je me souviens bien ce qui est dit dans la norme SQL92 c'est que les valeurs numériques n'ont pas besoin de quote pas qu'elles ne doivent pas en avoir.
Le seul problème qui puisse se poser est lorsque la variable vaut NULL, ce qui est quand même extrêmement rare pour des données entrées par l'utilisateur.
Après, si on veut aller plus loin, on peut écrire des fonctions qui détermine si le champs doit être numérique ou non et ensuite tester si la variable est numérique ou non.
Le mieux étant d'avoir un SGBD qui supporte les requêtes préparées, on peut alors s'affranchir de la plupart des vérifications.
[SNIP]
Et, au passage, question portabilité (d'un SGBDR à un autre), votre code pose problème.
Si j'ai utiliser MySQL, c'est pour l'exemple.
Si on veut la portabilité, on utilise une couche d'abstraction qui pour la plupart ont leur fonction d'échappement qui ensuite fait appel à celle de mysql ou postgresql ... donc, là n'est pas le propos.
Patrick Mevzek
Le mieux étant d'avoir un SGBD qui supporte les requêtes préparées, on peut alors s'affranchir de la plupart des vérifications.
Non.
Et, au passage, question portabilité (d'un SGBDR à un autre), votre code pose problème.
Si j'ai utiliser MySQL, c'est pour l'exemple.
Si on veut la portabilité, on utilise une couche d'abstraction qui pour la plupart ont leur fonction d'échappement qui ensuite fait appel à celle de mysql ou postgresql ... donc, là n'est pas le propos.
Si c'est exactement le propos: manifestement les gens semblent croire qu'on résout les problèmes d'injection SQL en protégeant le caractère ' ou assimilé à coup de addslashes & compagnie.
C'est malheureusement une erreur, et tant que les gens n'auront pas compris que les problèmes d'injections SQL, comme d'autres d'ailleurs, sont plus généraux que ce qu'ils veulent bien voir, eh bien on aura toujours des applications vulnérables à l'injection SQL.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le mieux étant d'avoir un SGBD qui supporte les requêtes préparées, on
peut alors s'affranchir de la plupart des vérifications.
Non.
Et, au passage, question portabilité (d'un SGBDR à un autre), votre
code pose problème.
Si j'ai utiliser MySQL, c'est pour l'exemple.
Si on veut la portabilité, on utilise une couche d'abstraction qui pour
la plupart ont leur fonction d'échappement qui ensuite fait appel à
celle de mysql ou postgresql ... donc, là n'est pas le propos.
Si c'est exactement le propos: manifestement les gens semblent croire
qu'on résout les problèmes d'injection SQL en protégeant le caractère '
ou assimilé à coup de addslashes & compagnie.
C'est malheureusement une erreur, et tant que les gens n'auront pas
compris que les problèmes d'injections SQL, comme d'autres d'ailleurs,
sont plus généraux que ce qu'ils veulent bien voir, eh bien on aura
toujours des applications vulnérables à l'injection SQL.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le mieux étant d'avoir un SGBD qui supporte les requêtes préparées, on peut alors s'affranchir de la plupart des vérifications.
Non.
Et, au passage, question portabilité (d'un SGBDR à un autre), votre code pose problème.
Si j'ai utiliser MySQL, c'est pour l'exemple.
Si on veut la portabilité, on utilise une couche d'abstraction qui pour la plupart ont leur fonction d'échappement qui ensuite fait appel à celle de mysql ou postgresql ... donc, là n'est pas le propos.
Si c'est exactement le propos: manifestement les gens semblent croire qu'on résout les problèmes d'injection SQL en protégeant le caractère ' ou assimilé à coup de addslashes & compagnie.
C'est malheureusement une erreur, et tant que les gens n'auront pas compris que les problèmes d'injections SQL, comme d'autres d'ailleurs, sont plus généraux que ce qu'ils veulent bien voir, eh bien on aura toujours des applications vulnérables à l'injection SQL.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
ftc
Le mieux étant d'avoir un SGBD qui supporte les requêtes préparées, on peut alors s'affranchir de la plupart des vérifications.
Non.
Si. J'argumente pas plus.
Et, au passage, question portabilité (d'un SGBDR à un autre), votre code pose problème.
Si j'ai utiliser MySQL, c'est pour l'exemple.
Si on veut la portabilité, on utilise une couche d'abstraction qui pour la plupart ont leur fonction d'échappement qui ensuite fait appel à celle de mysql ou postgresql ... donc, là n'est pas le propos.
Si c'est exactement le propos: manifestement les gens semblent croire qu'on résout les problèmes d'injection SQL en protégeant le caractère ' ou assimilé à coup de addslashes & compagnie.
Je ne vois pas de rapport avec la portabilité dans votre réponse.
Mais pour vous répondre, on se protège des injections SQL en 'blanchissant' les variables, c'est à dire:
1) en isolant les caratères dangereux ( ajouter un backslash devant ' par exemple, supprimer les = s'ils n'ont rien à y faire ... ) et en protégeant la variable. C'est l'équivalent du tainted en PERL lorsque l'on est en mode strict
2) en s'assurant qu'une variable est une variable et non une instruction ( ce que font les SGBD disposant d'une fonction prepareSQL, on bind ensuite des variables ).
C'est malheureusement une erreur, et tant que les gens n'auront pas compris que les problèmes d'injections SQL, comme d'autres d'ailleurs, sont plus généraux que ce qu'ils veulent bien voir, eh bien on aura toujours des applications vulnérables à l'injection SQL.
Puisque vous en savez tant sur l'injection SQL, je vous propose de nous éclairer par vos lumières, ça fera peut être un peu avancer le débat plutôt que de répondre par des 'non' laconiques.
Le mieux étant d'avoir un SGBD qui supporte les requêtes préparées, on
peut alors s'affranchir de la plupart des vérifications.
Non.
Si. J'argumente pas plus.
Et, au passage, question portabilité (d'un SGBDR à un autre), votre
code pose problème.
Si j'ai utiliser MySQL, c'est pour l'exemple.
Si on veut la portabilité, on utilise une couche d'abstraction qui pour
la plupart ont leur fonction d'échappement qui ensuite fait appel à
celle de mysql ou postgresql ... donc, là n'est pas le propos.
Si c'est exactement le propos: manifestement les gens semblent croire
qu'on résout les problèmes d'injection SQL en protégeant le caractère '
ou assimilé à coup de addslashes & compagnie.
Je ne vois pas de rapport avec la portabilité dans votre réponse.
Mais pour vous répondre, on se protège des injections SQL en
'blanchissant' les variables, c'est à dire:
1) en isolant les caratères dangereux ( ajouter un backslash devant '
par exemple, supprimer les = s'ils n'ont rien à y faire ... ) et en
protégeant la variable. C'est l'équivalent du tainted en PERL lorsque
l'on est en mode strict
2) en s'assurant qu'une variable est une variable et non une instruction
( ce que font les SGBD disposant d'une fonction prepareSQL, on bind
ensuite des variables ).
C'est malheureusement une erreur, et tant que les gens n'auront pas
compris que les problèmes d'injections SQL, comme d'autres d'ailleurs,
sont plus généraux que ce qu'ils veulent bien voir, eh bien on aura
toujours des applications vulnérables à l'injection SQL.
Puisque vous en savez tant sur l'injection SQL, je vous propose de nous
éclairer par vos lumières, ça fera peut être un peu avancer le débat
plutôt que de répondre par des 'non' laconiques.
Le mieux étant d'avoir un SGBD qui supporte les requêtes préparées, on peut alors s'affranchir de la plupart des vérifications.
Non.
Si. J'argumente pas plus.
Et, au passage, question portabilité (d'un SGBDR à un autre), votre code pose problème.
Si j'ai utiliser MySQL, c'est pour l'exemple.
Si on veut la portabilité, on utilise une couche d'abstraction qui pour la plupart ont leur fonction d'échappement qui ensuite fait appel à celle de mysql ou postgresql ... donc, là n'est pas le propos.
Si c'est exactement le propos: manifestement les gens semblent croire qu'on résout les problèmes d'injection SQL en protégeant le caractère ' ou assimilé à coup de addslashes & compagnie.
Je ne vois pas de rapport avec la portabilité dans votre réponse.
Mais pour vous répondre, on se protège des injections SQL en 'blanchissant' les variables, c'est à dire:
1) en isolant les caratères dangereux ( ajouter un backslash devant ' par exemple, supprimer les = s'ils n'ont rien à y faire ... ) et en protégeant la variable. C'est l'équivalent du tainted en PERL lorsque l'on est en mode strict
2) en s'assurant qu'une variable est une variable et non une instruction ( ce que font les SGBD disposant d'une fonction prepareSQL, on bind ensuite des variables ).
C'est malheureusement une erreur, et tant que les gens n'auront pas compris que les problèmes d'injections SQL, comme d'autres d'ailleurs, sont plus généraux que ce qu'ils veulent bien voir, eh bien on aura toujours des applications vulnérables à l'injection SQL.
Puisque vous en savez tant sur l'injection SQL, je vous propose de nous éclairer par vos lumières, ça fera peut être un peu avancer le débat plutôt que de répondre par des 'non' laconiques.
Patrick Mevzek
Mais pour vous répondre, on se protège des injections SQL en 'blanchissant' les variables, c'est à dire:
Non. Vous n'avez pas compris le problème des injections SQL. Répéter à tue-tête une fausse solution ne va rien y changer...
C'est l'équivalent du tainted en PERL lorsque l'on est en mode strict
N'importe quoi. Vous ne connaissez manifestement pas ce dont vous parlez.
Puisque vous en savez tant sur l'injection SQL, je vous propose de nous éclairer par vos lumières,
Je vous ai *déjà* donné un exemple d'injection SQL sans ' (que vous croyez corriger en changeant la requête SQL et ce de manière non portable qui plus est), ce qui prouve bien qu'il ne suffit pas de mettre un backslash devant les ' pour subitement être invulnérable aux injections. Mais bon il n'y a pire aveugle que celui que ne veut pas voir...
Ca sera tout pour moi.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Mais pour vous répondre, on se protège des injections SQL en
'blanchissant' les variables, c'est à dire:
Non. Vous n'avez pas compris le problème des injections SQL.
Répéter à tue-tête une fausse solution ne va rien y changer...
C'est l'équivalent du tainted en PERL lorsque l'on est en mode strict
N'importe quoi. Vous ne connaissez manifestement pas ce dont vous parlez.
Puisque vous en savez tant sur l'injection SQL, je vous propose de nous
éclairer par vos lumières,
Je vous ai *déjà* donné un exemple d'injection SQL sans '
(que vous croyez corriger en changeant la requête SQL et ce de manière non
portable qui plus est), ce qui prouve bien qu'il ne suffit pas de mettre
un backslash devant les ' pour subitement être invulnérable aux
injections.
Mais bon il n'y a pire aveugle que celui que ne veut pas voir...
Ca sera tout pour moi.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Mais pour vous répondre, on se protège des injections SQL en 'blanchissant' les variables, c'est à dire:
Non. Vous n'avez pas compris le problème des injections SQL. Répéter à tue-tête une fausse solution ne va rien y changer...
C'est l'équivalent du tainted en PERL lorsque l'on est en mode strict
N'importe quoi. Vous ne connaissez manifestement pas ce dont vous parlez.
Puisque vous en savez tant sur l'injection SQL, je vous propose de nous éclairer par vos lumières,
Je vous ai *déjà* donné un exemple d'injection SQL sans ' (que vous croyez corriger en changeant la requête SQL et ce de manière non portable qui plus est), ce qui prouve bien qu'il ne suffit pas de mettre un backslash devant les ' pour subitement être invulnérable aux injections. Mais bon il n'y a pire aveugle que celui que ne veut pas voir...
Ca sera tout pour moi.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
ftc
Mais pour vous répondre, on se protège des injections SQL en 'blanchissant' les variables, c'est à dire:
Non. Vous n'avez pas compris le problème des injections SQL. Répéter à tue-tête une fausse solution ne va rien y changer...
Et bien expliquez nous donc quelles sont vos brillantes solutions.
C'est l'équivalent du tainted en PERL lorsque l'on est en mode strict
N'importe quoi. Vous ne connaissez manifestement pas ce dont vous parlez.
Je crois plutôt que vous ne connaissez pas le principe des variables tainted en PERL, vous savez, lorsqu'on ajoute -T comme commutateur.
Puisque vous en savez tant sur l'injection SQL, je vous propose de nous éclairer par vos lumières,
Je vous ai *déjà* donné un exemple d'injection SQL sans ' (que vous croyez corriger en changeant la requête SQL et ce de manière non portable qui plus est), ce qui prouve bien qu'il ne suffit pas de mettre un backslash devant les ' pour subitement être invulnérable aux injections.
Qui a dis qu'il suffisait de mettre un backslash devant les ' pour se prémunir des injections SQL ?
Je ne vous demande pas quelles sont les méthodes d'injection SQL, mais de quelles manières vous résolvez le problème afin de faire avancer un peu le débat. Je constate que vous critiquez, vous critiquez ... vous critiquez mais n'apportez jamais de solution.
Ca sera tout pour moi.
C'est marrant, c'est votre réponse à chaque fois que vous ne pouvez apporter d'arguments.
Mais pour vous répondre, on se protège des injections SQL en
'blanchissant' les variables, c'est à dire:
Non. Vous n'avez pas compris le problème des injections SQL.
Répéter à tue-tête une fausse solution ne va rien y changer...
Et bien expliquez nous donc quelles sont vos brillantes solutions.
C'est l'équivalent du tainted en PERL lorsque l'on est en mode strict
N'importe quoi. Vous ne connaissez manifestement pas ce dont vous parlez.
Je crois plutôt que vous ne connaissez pas le principe des variables
tainted en PERL, vous savez, lorsqu'on ajoute -T comme commutateur.
Puisque vous en savez tant sur l'injection SQL, je vous propose de nous
éclairer par vos lumières,
Je vous ai *déjà* donné un exemple d'injection SQL sans '
(que vous croyez corriger en changeant la requête SQL et ce de manière non
portable qui plus est), ce qui prouve bien qu'il ne suffit pas de mettre
un backslash devant les ' pour subitement être invulnérable aux
injections.
Qui a dis qu'il suffisait de mettre un backslash devant les ' pour se
prémunir des injections SQL ?
Je ne vous demande pas quelles sont les méthodes d'injection SQL, mais
de quelles manières vous résolvez le problème afin de faire avancer un
peu le débat. Je constate que vous critiquez, vous critiquez ... vous
critiquez mais n'apportez jamais de solution.
Ca sera tout pour moi.
C'est marrant, c'est votre réponse à chaque fois que vous ne pouvez
apporter d'arguments.
Mais pour vous répondre, on se protège des injections SQL en 'blanchissant' les variables, c'est à dire:
Non. Vous n'avez pas compris le problème des injections SQL. Répéter à tue-tête une fausse solution ne va rien y changer...
Et bien expliquez nous donc quelles sont vos brillantes solutions.
C'est l'équivalent du tainted en PERL lorsque l'on est en mode strict
N'importe quoi. Vous ne connaissez manifestement pas ce dont vous parlez.
Je crois plutôt que vous ne connaissez pas le principe des variables tainted en PERL, vous savez, lorsqu'on ajoute -T comme commutateur.
Puisque vous en savez tant sur l'injection SQL, je vous propose de nous éclairer par vos lumières,
Je vous ai *déjà* donné un exemple d'injection SQL sans ' (que vous croyez corriger en changeant la requête SQL et ce de manière non portable qui plus est), ce qui prouve bien qu'il ne suffit pas de mettre un backslash devant les ' pour subitement être invulnérable aux injections.
Qui a dis qu'il suffisait de mettre un backslash devant les ' pour se prémunir des injections SQL ?
Je ne vous demande pas quelles sont les méthodes d'injection SQL, mais de quelles manières vous résolvez le problème afin de faire avancer un peu le débat. Je constate que vous critiquez, vous critiquez ... vous critiquez mais n'apportez jamais de solution.
Ca sera tout pour moi.
C'est marrant, c'est votre réponse à chaque fois que vous ne pouvez apporter d'arguments.
Guillaume Bouchard
Patrick Mevzek wrote:
On peut faire une injection SQL sans utiliser le '
Exemple avec la requête SQL: SELECT * FROM whatever WHERE id=$_POST[id]
il suffit d'envoyer dans $_POST[id]: 0 OR 1 pour élargir grandement la restriction initiale.
Comment une variable qui devrait contenir un entier contient-t-elle une chaine de caractére ? Elle n'a pas été traitée avant ?
Recapitulons mon humble avis sur les injections sql :
1) Il faut verifier ces variables, faire sauter celle qui n'ont pas le bon type (string aulieu de integer). 2) Il faut echapper avec la fonction d'echapement qui va bien les caractéres à echapper. 3) Je rappel aussi qu'on ne verifie pas qu'une variable ne possede pas de caractére interdit, mais qu'elle possede que les caractéres autorisés.
-- Guillaume.
Patrick Mevzek wrote:
On peut faire une injection SQL sans utiliser le '
Exemple avec la requête SQL:
SELECT * FROM whatever WHERE id=$_POST[id]
il suffit d'envoyer dans $_POST[id]:
0 OR 1
pour élargir grandement la restriction initiale.
Comment une variable qui devrait contenir un entier contient-t-elle une
chaine de caractére ?
Elle n'a pas été traitée avant ?
Recapitulons mon humble avis sur les injections sql :
1) Il faut verifier ces variables, faire sauter celle qui n'ont pas le
bon type (string aulieu de integer).
2) Il faut echapper avec la fonction d'echapement qui va bien les
caractéres à echapper.
3) Je rappel aussi qu'on ne verifie pas qu'une variable ne possede pas
de caractére interdit, mais qu'elle possede que les caractéres autorisés.
On peut faire une injection SQL sans utiliser le '
Exemple avec la requête SQL: SELECT * FROM whatever WHERE id=$_POST[id]
il suffit d'envoyer dans $_POST[id]: 0 OR 1 pour élargir grandement la restriction initiale.
Comment une variable qui devrait contenir un entier contient-t-elle une chaine de caractére ? Elle n'a pas été traitée avant ?
Recapitulons mon humble avis sur les injections sql :
1) Il faut verifier ces variables, faire sauter celle qui n'ont pas le bon type (string aulieu de integer). 2) Il faut echapper avec la fonction d'echapement qui va bien les caractéres à echapper. 3) Je rappel aussi qu'on ne verifie pas qu'une variable ne possede pas de caractére interdit, mais qu'elle possede que les caractéres autorisés.
-- Guillaume.
ftc
Recapitulons mon humble avis sur les injections sql :
1) Il faut verifier ces variables, faire sauter celle qui n'ont pas le bon type (string aulieu de integer). 2) Il faut echapper avec la fonction d'echapement qui va bien les caractéres à echapper. 3) Je rappel aussi qu'on ne verifie pas qu'une variable ne possede pas de caractére interdit, mais qu'elle possede que les caractéres autorisés.
Tout à fait d'accord, sauf sur le troisième point qui ne peut pas toujours être mis en place, cas de données ou les caractères autorisés ne sont pas déterminables, on doit donc faire avec les caractères interdits à ce moment.
Recapitulons mon humble avis sur les injections sql :
1) Il faut verifier ces variables, faire sauter celle qui n'ont pas le
bon type (string aulieu de integer).
2) Il faut echapper avec la fonction d'echapement qui va bien les
caractéres à echapper.
3) Je rappel aussi qu'on ne verifie pas qu'une variable ne possede pas
de caractére interdit, mais qu'elle possede que les caractéres autorisés.
Tout à fait d'accord, sauf sur le troisième point qui ne peut pas
toujours être mis en place, cas de données ou les caractères autorisés
ne sont pas déterminables, on doit donc faire avec les caractères
interdits à ce moment.
Recapitulons mon humble avis sur les injections sql :
1) Il faut verifier ces variables, faire sauter celle qui n'ont pas le bon type (string aulieu de integer). 2) Il faut echapper avec la fonction d'echapement qui va bien les caractéres à echapper. 3) Je rappel aussi qu'on ne verifie pas qu'une variable ne possede pas de caractére interdit, mais qu'elle possede que les caractéres autorisés.
Tout à fait d'accord, sauf sur le troisième point qui ne peut pas toujours être mis en place, cas de données ou les caractères autorisés ne sont pas déterminables, on doit donc faire avec les caractères interdits à ce moment.
Patrick Mevzek
Comment une variable qui devrait contenir un entier contient-t-elle une chaine de caractére ?
Quand on ne fait aucun test dessus, et quand on applique la méthode donnée par beaucoup ici: il suffit de faire addslashes() et le problème est résolu. Ce qui est faux.
Elle n'a pas été traitée avant ?
Recapitulons mon humble avis sur les injections sql :
1) Il faut verifier ces variables, faire sauter celle qui n'ont pas le bon type (string aulieu de integer). 2) Il faut echapper avec la fonction d'echapement qui va bien les caractéres à echapper.
Voilà, *ca* c'est la bonne procédure, mais le 1) semble souvent passser à la trappe, les gens ne font que le 2)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Comment une variable qui devrait contenir un entier contient-t-elle une
chaine de caractére ?
Quand on ne fait aucun test dessus, et quand on applique la méthode
donnée par beaucoup ici: il suffit de faire addslashes() et le problème
est résolu. Ce qui est faux.
Elle n'a pas été traitée avant ?
Recapitulons mon humble avis sur les injections sql :
1) Il faut verifier ces variables, faire sauter celle qui n'ont pas le
bon type (string aulieu de integer).
2) Il faut echapper avec la fonction d'echapement qui va bien les
caractéres à echapper.
Voilà, *ca* c'est la bonne procédure, mais le 1) semble souvent passser à
la trappe, les gens ne font que le 2)
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Comment une variable qui devrait contenir un entier contient-t-elle une chaine de caractére ?
Quand on ne fait aucun test dessus, et quand on applique la méthode donnée par beaucoup ici: il suffit de faire addslashes() et le problème est résolu. Ce qui est faux.
Elle n'a pas été traitée avant ?
Recapitulons mon humble avis sur les injections sql :
1) Il faut verifier ces variables, faire sauter celle qui n'ont pas le bon type (string aulieu de integer). 2) Il faut echapper avec la fonction d'echapement qui va bien les caractéres à echapper.
Voilà, *ca* c'est la bonne procédure, mais le 1) semble souvent passser à la trappe, les gens ne font que le 2)
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Patrick Mevzek
Non. Vous n'avez pas compris le problème des injections SQL. Répéter à tue-tête une fausse solution ne va rien y changer...
Et bien expliquez nous donc quelles sont vos brillantes solutions.
Déjà fait, mais quand on ne veut pas voir, on ne veut pas...
C'est l'équivalent du tainted en PERL lorsque l'on est en mode strict
N'importe quoi. Vous ne connaissez manifestement pas ce dont vous parlez.
Je crois plutôt que vous ne connaissez pas le principe des variables tainted en PERL, vous savez, lorsqu'on ajoute -T comme commutateur.
Allez-y, allez-y, continuer à vous enliser...
Puisque vous en savez tant sur l'injection SQL, je vous propose de nous éclairer par vos lumières,
Je vous ai *déjà* donné un exemple d'injection SQL sans ' (que vous croyez corriger en changeant la requête SQL et ce de manière non portable qui plus est), ce qui prouve bien qu'il ne suffit pas de mettre un backslash devant les ' pour subitement être invulnérable aux injections.
Qui a dis qu'il suffisait de mettre un backslash devant les ' pour se prémunir des injections SQL ?
Parce que mysql_real_escape_string dont vous parlez dans <429c8c3c$0$16624$ ca fait quoi peut-être ?
Ca sera tout pour moi.
C'est marrant, c'est votre réponse à chaque fois que vous ne pouvez apporter d'arguments.
Le problème avec vous c'est que quand on donne un argument vous faites mine de ne pas le voir. Je n'ai donc pas de temps à perdre à vous expliquer les évidences, compte tenu de plus du fait que ce n'est pas le premier fil que j'ai le malheur de partager avec vous, et donc je vois bien que cela ne va pas changer.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Non. Vous n'avez pas compris le problème des injections SQL. Répéter à
tue-tête une fausse solution ne va rien y changer...
Et bien expliquez nous donc quelles sont vos brillantes solutions.
Déjà fait, mais quand on ne veut pas voir, on ne veut pas...
C'est l'équivalent du tainted en PERL lorsque l'on est en mode strict
N'importe quoi. Vous ne connaissez manifestement pas ce dont vous
parlez.
Je crois plutôt que vous ne connaissez pas le principe des variables
tainted en PERL, vous savez, lorsqu'on ajoute -T comme commutateur.
Allez-y, allez-y, continuer à vous enliser...
Puisque vous en savez tant sur l'injection SQL, je vous propose de nous
éclairer par vos lumières,
Je vous ai *déjà* donné un exemple d'injection SQL sans ' (que vous
croyez corriger en changeant la requête SQL et ce de manière non
portable qui plus est), ce qui prouve bien qu'il ne suffit pas de
mettre un backslash devant les ' pour subitement être invulnérable aux
injections.
Qui a dis qu'il suffisait de mettre un backslash devant les ' pour se
prémunir des injections SQL ?
Parce que mysql_real_escape_string dont vous parlez dans
<429c8c3c$0$16624$626a14ce@news.free.fr>
ca fait quoi peut-être ?
Ca sera tout pour moi.
C'est marrant, c'est votre réponse à chaque fois que vous ne pouvez
apporter d'arguments.
Le problème avec vous c'est que quand on donne un argument vous faites
mine de ne pas le voir. Je n'ai donc pas de temps à perdre à vous
expliquer les évidences, compte tenu de plus du fait que ce n'est pas le
premier fil que j'ai le malheur de partager avec vous, et donc je vois
bien que cela ne va pas changer.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Non. Vous n'avez pas compris le problème des injections SQL. Répéter à tue-tête une fausse solution ne va rien y changer...
Et bien expliquez nous donc quelles sont vos brillantes solutions.
Déjà fait, mais quand on ne veut pas voir, on ne veut pas...
C'est l'équivalent du tainted en PERL lorsque l'on est en mode strict
N'importe quoi. Vous ne connaissez manifestement pas ce dont vous parlez.
Je crois plutôt que vous ne connaissez pas le principe des variables tainted en PERL, vous savez, lorsqu'on ajoute -T comme commutateur.
Allez-y, allez-y, continuer à vous enliser...
Puisque vous en savez tant sur l'injection SQL, je vous propose de nous éclairer par vos lumières,
Je vous ai *déjà* donné un exemple d'injection SQL sans ' (que vous croyez corriger en changeant la requête SQL et ce de manière non portable qui plus est), ce qui prouve bien qu'il ne suffit pas de mettre un backslash devant les ' pour subitement être invulnérable aux injections.
Qui a dis qu'il suffisait de mettre un backslash devant les ' pour se prémunir des injections SQL ?
Parce que mysql_real_escape_string dont vous parlez dans <429c8c3c$0$16624$ ca fait quoi peut-être ?
Ca sera tout pour moi.
C'est marrant, c'est votre réponse à chaque fois que vous ne pouvez apporter d'arguments.
Le problème avec vous c'est que quand on donne un argument vous faites mine de ne pas le voir. Je n'ai donc pas de temps à perdre à vous expliquer les évidences, compte tenu de plus du fait que ce n'est pas le premier fil que j'ai le malheur de partager avec vous, et donc je vois bien que cela ne va pas changer.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
