les "," dans une requete SQL

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

J'ai beau relire vos posts dans ce fil, je ne voit rien qui ressemble à
un début de proposition, je ne vois que des critiques de tout ce qui est
proposé, mais je dois être complètement aveugle.


[SNIP]

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 ?

C'est bien que vous citiez ce message puisque justement je montre qu'il
ne suffit pas de faire un mysql_real_escape_string, on voit bien ( enfin
moi et d'autres personnes j'espère ) qu'il y a *en plus* des *quotes
autour*. Je vous met au défit de réaliser une injection SQL avec cette
méthode.

Que cette méthode ne vous plaise pas est une autre chose, il y a
d'autres méthodes pour 'blanchir' une variable ( la rendre inoffesive ).

J'ai beau relire vos posts dans ce fil, je ne voit rien qui ressemble à
un début de proposition, je ne vois que des critiques de tout ce qui est
proposé, mais je dois être complètement aveugle.

Pourquoi persistez-vous à vouloir dialoguer avec moi alors si d'après
vous je ne fais que critiquer ?

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 ?

C'est bien que vous citiez ce message puisque justement je montre qu'il
ne suffit pas de faire un mysql_real_escape_string, on voit bien ( enfin
moi et d'autres personnes j'espère ) qu'il y a *en plus* des *quotes
autour*.

Ce qui continue à propager l'idée que ce genre de fonctions suffit, idée
que je refuse, comme dit dans l'autre partie du thread, il y a une
*autre* étape à appliquer avant.
Ce que propage aussi la documentation PHP, m'enfin PHP et la sécurité, on
sait ce que ca vaut...

D'autre part regardez autour de vous: on n'utilise les ' dans les
requêtes SQL que pour les chaines de caractère.
Donc, selon vous, résoudre le problème des injections SQL en changeant
les requêtes SQL, c'est tout sauf une solution selon moi, car le problème
du contenu des variables peut se reposer ailleurs dans le programme
(indépendamment des requêtes SQL), et que donc selon moi il est bien plus
intéressant et utile en termes de sécurité de passer du temps sur le
contenu des variables (et en particulier vérifier leur format), que de
bidouiller des requêtes SQL, surtout si c'est pour les rendre non
portables
(alors que l'un des problèmes majeurs des applications Web c'est d'être
portables d'un SGBDR à un autre)

Je vous met au défit de réaliser une injection SQL avec cette
méthode.

Vous payez bien ?
Je vous donne un conseil gratuit: lisez la documentation, et vous verrez
que % n'est pas protégé, par exemple.
Donc:
"SELECT * FROM annuaire WHERE name LIKE '".mysql_real_escape_string($id)."'"
avec $id='%', et pouf vous récupérez tout...
(alors que sinon LIKE 'toto' sans % vous donne que les résultats avec
toto pile poil, donc on pourrait légitimement penser utiliser une telle
requête similaire à =)

Deuxième conseil gratuit (je suis très généreux ce soir): mysql_truc ne
protège en rien contre un contenu exagérement grand.

Tout ceci doit vous faire arriver à la conclusion que:
ces fonctions sont INUTILES si vous ne faites pas AVANT un test sur le
CONTENU des variables et notamment leur FORMAT.

Ca y est c'est suffisamment clair devant vos yeux ou vous allez encore
trouver à y redire ?

Que cette méthode ne vous plaise pas est une autre chose, il y a
d'autres méthodes pour 'blanchir' une variable ( la rendre inoffesive
).

Oui, effectivement, il y a des bonnes méthodes de le faire, c'est ce que
je dis dès le début.

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

D'autre part regardez autour de vous: on n'utilise les ' dans les
requêtes SQL que pour les chaines de caractère.

Et bien justement, si on en mettait ailleurs ce ne serait pas une
mauvaise chose puisque la norme l'autorise. Ce n'est pas parcequ'une
pratique est largement utilisée qu'elle est forcément bonne.

car le problème
du contenu des variables peut se reposer ailleurs dans le programme
(indépendamment des requêtes SQL), et que donc selon moi il est bien plus
intéressant et utile en termes de sécurité de passer du temps sur le
contenu des variables (et en particulier vérifier leur format), que de
bidouiller des requêtes SQL,

On sort donc largement du cadre des injections SQL qui étaient quand
même le fond du débat.

Je n'ai jamais dis qu'il ne fallait faire aucun test sur les variables,
bien évidemment qu'on teste les variables. Mais dans certains cas, les
caractères dangereux doivent quand même pouvoir être saisis et là il
faut bien se protéger des injections SQL non ?

Donc, oui il faut tester les variables mais ce n'est que rarement
suffisant, il faut donc aussi *bidouiller* des requetes SQL.

surtout si c'est pour les rendre non
portables
(alors que l'un des problèmes majeurs des applications Web c'est d'être
portables d'un SGBDR à un autre)

Etre portable à condition que l'application doivent être distribuée à
grande échelle.
Lorsqu'on réalise une application pour un client qui ne doit pas être
distribuée, on réalise un cahier des charges avec des spécifications
techniques afin de s'adapter au mieux à ses besoins.
Je n'ai jamais eu de client à me demander de faire une application
portable d'un SGBDR à l'autre, au contraire même, on demande en général
d'utiliser au maximum les possibilité du SGBDR et notament les
procédures stockées avec PostgreSQL ou Oracle.

Je vous met au défit de réaliser une injection SQL avec cette
méthode.

Vous payez bien ?
Je vous donne un conseil gratuit: lisez la documentation, et vous verrez
que % n'est pas protégé, par exemple.
Donc:
"SELECT * FROM annuaire WHERE name LIKE '".mysql_real_escape_string($id)."'"
avec $id='%', et pouf vous récupérez tout...

Et bien forcément, si vous changez les données du problème, c'est tout
de suite plus facile.

C'est marrant, vous pronez sans arret l'utilisation de *bonnes
techniques* et vous me pondez une requête avec un LIKE, laissez moi
pouffer quand même. Si vous utilisez des LIKE dans des requêtes
sensibles, forcément on ne va vraiment pas être d'accord.

Si on fait une requête avec un LIKE, c'est qu'on offre la possibilité à
l'utilisateur de faire des recherches ( enfin je peux me tromper, mais
c'est vraiment le seul cas ou je trouve une utilité au LIKE ), je ne
vois donc pas pourquoi il ne pourrait pas utiliser '%' puisque ça
correspond à une requête de recherche, surtout que LIKE est normalement
utilisé avec des actions de type LIMIT ou autre sur d'autre SGBDR donc
aucun risque de mettre celui-ci par terre.

Au passage, je ne vois vraiment pas l'intéret d'utiliser LIKE pour ne
pas utiliser '%' ou '_', dans ce cas on utilise l'égalité.

Il ne faudrait peut être pas voir des failles de sécurité ou il n'y en a
pas.

Vous me faites pensez à une personne avec qui j'ai travaillé qui clamait
haut et fort que de faire apparaitre une adresse IP était une faille de
sécurité.

car le problème
du contenu des variables peut se reposer ailleurs dans le programme
(indépendamment des requêtes SQL), et que donc selon moi il est bien
plus intéressant et utile en termes de sécurité de passer du temps sur
le contenu des variables (et en particulier vérifier leur format), que
de bidouiller des requêtes SQL,

On sort donc largement du cadre des injections SQL qui étaient quand
même le fond du débat.

Le fond du débat c'est la sécurité. Et propager l'idée que addslashes,
mysql_truc et compagnie c'est la seule chose que l'on ait besoin de faire
pour régler le problème des injections SQL, cela fait partie des choses
dont il faudrait une fois pour toute tordre le cou.

surtout si c'est pour les rendre non
portables
(alors que l'un des problèmes majeurs des applications Web c'est
d'être portables d'un SGBDR à un autre)

Etre portable à condition que l'application doivent être distribuée à
grande échelle.

Non, mais peu importe.

Je vous met au défit de réaliser une injection SQL avec cette méthode.

Vous payez bien ?
Je vous donne un conseil gratuit: lisez la documentation, et vous
verrez que % n'est pas protégé, par exemple. Donc: "SELECT * FROM
annuaire WHERE name LIKE '".mysql_real_escape_string($id)."'" avec
$id='%', et pouf vous récupérez tout...

Et bien forcément, si vous changez les données du problème, c'est tout
de suite plus facile.

C'est bien ce que je disais: à chaque fois qu'on présente un exemple,
vous faites mine de ne pas le voir.

Comment voulez-vous qu'on trouve après un intérêt à faire un effort ?
Ca m'apprendra en tout cas.

Il ne faudrait peut être pas voir des failles de sécurité ou il n'y en a
pas.

Bah voyons. Bon allez je vous laisse dans votre monde magique où
mysql_real_escape_string() corrige tous les problèmes d'injections SQL.

Vous me faites pensez à une personne avec qui j'ai travaillé qui clamait
haut et fort que de faire apparaitre une adresse IP était une faille de
sécurité.

Heureux de faire travailler votre mémoire.

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

Je vais répondre une dernière fois car vous ne cessez de déformer mes
propos.

Le fond du débat c'est la sécurité. Et propager l'idée que addslashes,
mysql_truc et compagnie c'est la seule chose que l'on ait besoin de faire
pour régler le problème des injections SQL, cela fait partie des choses
dont il faudrait une fois pour toute tordre le cou.

Ou est-ce que j'ai dit qu'il ne fallait que des addslashes pour protéger
une application ?

J'ai proposé une solution qui fonctionne contre les injections SQL,
qu'elle vous plaise ou non est un autre débat.

Le fait de tester si une valeur qui doit être numérique est bien
numérique ou qu'elle ne contient que certains caractères est une base du
développement d'application qui a plus à voir avec la cohérence de
l'application en elle même.
Ce sont des choses que l'on fait même lorsque l'application n'a pas à
être sécurisée.
Dire que c'est de la sécurité est plus valorisant mais montre un grave
défaut de conception.

Vous vous cachez derrière une pseudo-portabilité qui n'est que rarement
au coeur du problème lorsque l'on développe une application pour un
client ou pour soi-même, c'est même en général le contraire.
La priorité d'une application métier n'est pas la portabilité, c'est
plutôt la rapidité, la tolérance aux pannes et aux montés en charge,
bref tout le contraire de la portabilité.

Je vous ai lancé un défit que vous n'avez pas voulu ( su ? ) relever. Ce
n'est pas en changeant les données du problème qu'on fait avancer les
choses, on appelle cela de la langue de bois.


[SNIP]

C'est bien ce que je disais: à chaque fois qu'on présente un exemple,
vous faites mine de ne pas le voir.

Le problème est que votre exemple ne présente strictement aucune faille
comme je l'explique dans le post précédent, quel en est donc l'intéret ?

Le problème de laisser l'accès au '%' et '_' dans une instruction LIKE
n'a rien avoir avec la sécurité, c'est plutôt un débat sur l'utilité du
LIKE car si on interdit l'utilisation de '%' ou '_' autant prendre une
condition d'égalité.

Comment voulez-vous qu'on trouve après un intérêt à faire un effort ?
Ca m'apprendra en tout cas.

Si vous présentiez un exemple qui a effectivement une faille, ce serait
plus intéressant quand même vous ne croyez pas ?

Au fait, personne ne vous demande de faire des efforts et surtout pas
moi. Ce serait juste bien de faire progresser un peu le débat.

Je vais répondre une dernière fois

Ouf !

car vous ne cessez de déformer mes propos.

Les pauvres.

Je vous ai lancé un défit que vous n'avez pas voulu ( su ? ) relever.

Encore un exemple typique de ce que je disais: je vous donne 2 exemples
à votre soi-disant défi, l'un vous ergotez dessus, et l'autre vous le
faites disparaitre.
Il n'y a pire aveugle...

C'est bien ce que je disais: à chaque fois qu'on présente un exemple,
vous faites mine de ne pas le voir.

Le problème est que votre exemple ne présente strictement aucune faille

Ah c'est donc pire que ce que je pensais, malheureusement... vous ne
voyez pas la faille !

Si vous présentiez un exemple qui a effectivement une faille, ce serait
plus intéressant quand même vous ne croyez pas ?

Si vous daigniez regarder les exemples qu'on vous donne, ce serait
plus intéressant quand même vous ne croyez pas ?

Au fait, personne ne vous demande de faire des efforts et surtout pas
moi.

Relisez-vous alors !

Ce serait juste bien de faire progresser un peu le débat.

Je suis sûr que vous êtes persuadés que c'est votre cas. Donc tout va
bien.

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