anti injections

Il ne faut pas m'en vouloir si je pose des questions qui n'ont pas de sens.

Ces technologies sont un vrai défi pour une peintre de 68 ans.
Je suis très curieuse et avide de comprendre tout cela.

J'ai découvert le html par moi-même et maintenant j'espère apprendre
suffisamment le php pour me monter un petit site pour mes tableaux. Mais je
ne veux pas me le faire salir à la première occasion. Il est plus difficile
je crois de nettoyer les saloperies des pirates que de s'en protéger.

Alors terminé pour les mouchoirs.

Dans mon message le <$b> voulait dire que au lieu de mettre une balise de
caractère gras si on remplace le "b" par un script, ici représenté par "$b"
, le contenu de ce dangeureux script est transmis.

Par ex. si $b = "exec(touch /fichier1)" , cette commande sera-t-elle
exécutée ?

Dans mon script ereg tout ce qui est balisé par < > entre autre, est ciblé
donc peut être remplacé par "" par exemple. Non ?

J'ai pas compris... Comment $b peut-il être un script malicieux? Il
existe une grande différence entre la sécurisation des variables
d'entrées, et les regexp utilisées pour permettre l'utilisation de code
html dans ses formulaires, dans les deux cas, votre remarque n'a pas de

Donc si je comprend bien dans un formulaire, pour endommager mon site, on
devrait taper quelque chose du genre: ceci est un "<?php
unlink(unfichier); ?>" mauvais coup
dans un espace de saisie !?

Si magic_quotes est actif alors les " sont remplacés par " ce qui invalide
l'action et retransmet le segment "<?php unlink(unfichier); ?>" qui
devient donc un simple string et non une commande à exécuter.

htmlentities appliqué à la valeur de l'espace de saisie du formulaire
retransmet aussi un string au lieu de la commande. Je comprend bien ?

Donc en plus de magic_quotes, utiliser htmlentities rend mon script
anti-injection inutile.

Notez-moi s.v.p.

Non : PHP ne remplace le contenu des variable dans une chaine de caractère
uniquement si elles sont explicitement écrites entre guillemets doubles.
Par exemple $foo = 'bar'; echo "Foo $foo"; affichera Foo bar
et $foo = '$bar'; echo "Foo $foo" affichera bien Foo $bar (même si $bar
est

une variable qui existe) : l'interpreteur voit $foo dans une chaine avec
des

guillemets double, il remplace par la valeur et s'arrête là.

--
Vincent

Donc si je comprend bien dans un formulaire, pour endommager mon site, on
devrait taper quelque chose du genre: ceci est un "<?php
unlink(unfichier); ?>" mauvais coup
dans un espace de saisie !?

Non, je me suis mal exprimé...
PHP n'interprete que les variables qui sont entre des guillemets doubles
dans le script, et ce pas récursivement. Si quelqu'un tape ce que tu dis, tu
te retrouves avec une chaine de caracteres qui contient tous les caracteres
que tu as écrit. PHP ne va jamais l'executer (sauf si tu fais un eval
dessus, mais si tu fais eval sur une chaine entrée par l'utilisateur de ton
site, il y a clairement un problème de sécurité)

Si magic_quotes est actif alors les " sont remplacés par " ce qui
invalide
l'action et retransmet le segment "<?php unlink(unfichier); ?>" qui
devient donc un simple string et non une commande à exécuter.

Que magic quotes soit actif ou non, tu récupères de toutes facon une simple
chaine

htmlentities appliqué à la valeur de l'espace de saisie du formulaire
retransmet aussi un string au lieu de la commande. Je comprend bien ?

htmlentities permet seulement d'éviter que quelqu'un entre des balises html
dans ton code. En fait je pensais que tu parlais de ca comme injection... Si
tu fais un livre d'or par exemple, et que quelqu'un peut y ajouter
</body></html> (fermant ainsi ta page), c'est dommage. Faire un htmlentities
sur "</body></html>" le transforme de façon à ce que </body></html> soit
affiché sur la page (ce qui est le comportement voulu puisque c'est ce que
l'utilisateur a entré) et non pas interprété comme des balises HTML.

--
Vincent

PS: répond sous le message auquel tu réponds, pas au dessus
Ne quote pas l'intégralité du message, mais seulement les passages auquel tu
réponds.

N.K. Cole wrote:

Il ne faut pas m'en vouloir si je pose des questions qui n'ont pas de sens.

Pas de mal. Les seules questions idiotes sont celles qu'on ne pose pas
de peur de passer pour un idiot. Mais il ne faut pas se froisser non
plus si certaines réponses sont parfois un peu abruptes - sur usenet, le
port du gilet pare-balles est vivement conseillé !-)

Ces technologies sont un vrai défi pour une peintre de 68 ans.
Je suis très curieuse et avide de comprendre tout cela.

Courage.

J'ai découvert le html par moi-même et maintenant j'espère apprendre
suffisamment le php pour me monter un petit site pour mes tableaux. Mais je
ne veux pas me le faire salir à la première occasion. Il est plus difficile
je crois de nettoyer les saloperies des pirates que de s'en protéger.

Le plus simple dans ce cas est de ne pas permettre aux visiteurs de

remonter quoi que ce soit sur le serveur.

Mon premier bricolage en PHP était également une galerie virtuelle, et
je n'ai pas eu pour le moment de problèmes de sécurité avec... NB : pas
de forums, pas de "livre d'or", pas de formulaires, juste de l'affichage.

--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"

Bonjour Vincent

te retrouves avec une chaine de caracteres qui contient tous les
caracteres

que tu as écrit. PHP ne va jamais l'executer (sauf si tu fais un eval
dessus, mais si tu fais eval sur une chaine entrée par l'utilisateur de
ton

site, il y a clairement un problème de sécurité)

Et dans ce cas c'est moi le problème !! C'est comme si je disais au pirate
"tu as manqué ton coup tiens je vais t'aider "

Que magic quotes soit actif ou non, tu récupères de toutes facon une
simple

chaine

Alors si ce qui est entré en saisie n'est autre qu'une chaine, il n'y a
aucun moyen de causer des dommages de cette façon. Du point de vue du
vandale.

htmlentities permet seulement d'éviter que quelqu'un entre des balises
html

dans ton code. En fait je pensais que tu parlais de ca comme injection...
Si

Alors seulement les balises html peuvent être interprétées dans les champs
de saisie.

J'écris un formulaire d'inscription pour les visiteurs. Le formulaire
complété j'affiche une page avec le résultat des champs de saisie et ceux
dont format entré ne correspond pas sont identifiés. Si un nom comprend des
chiffres il est inscrit en rouge.

Donc pour me protéger de scripts malicieux je dois filtrer les champs. Je le
fais avec des regex. L'affichage des champs ressemble à ceci:

echo $ligne = (eregi(un_filtre_quelconque,$champ_de_saisie) : "..... color blue " ? " ..... color=red" ) . $champ_de_saisie ;

De cette façon je commande l'interprétation du script malicieux non ? et je
cause mon propre malheur.

au lieu d'utiliser eregi si j'utilise ereg_replace je pourrais alors
remplacer la portion invalide de la saisie par un message genre "Portion
invalide" et éviter l'interprétation. D'accord ?

Avec htmlentities, le filtre pourrait ressembler gosso-modo à

$filtre=htmlentities("<" etc )
eregi_replace($filtre, htmlentities($champ_de_saisie))

ca a du sens ?

Bonjour

Le plus simple dans ce cas est de ne pas permettre aux visiteurs de
remonter quoi que ce soit sur le serveur.

Mon premier bricolage en PHP était également une galerie virtuelle, et
je n'ai pas eu pour le moment de problèmes de sécurité avec... NB : pas
de forums, pas de "livre d'or", pas de formulaires, juste de l'affichage.

Mon premier site était une page personnelle chez un FSI. Si je vendais une
toile ou que j'e désirais modifier quoi que ce soit fallait se taper une
somme de travail que je trouvais indûe. C'est pourquoi j'ai opté pour PHP et
MySQL.

Maintenant il y aura un livre de visiteurs, l'affichage des prix selon la
devise choisie par le visiteur, achat en ligne, envoi d'invitations et
d'annonces me concernant à ceux qui auront désiré recevoir de l'information,
un calendrier d'événements intéressants sur l'art et d'autres services que
j'ai en tête.

Alors ce site, pas vraiment un site d'amateur par sa configuration, a besoin
de protection.

Une première est Linux. Puis du filtrage de saisie de données.

Mais je ne sais absolument pas comment un vilain peut injecter des
"vilainetés" dans les champs de saisie. On m'a dit que ca se faisait mais on
n'a pu me dire comment. Alors je cherche.

Pour contrer ces attaques il faut savoir les perpétrer.

Tu en sais quelque chose ? dis-moi.

N.K. Cole wrote:

Bonjour

Bonjour à vous,

Mon premier site était une page personnelle chez un FSI. Si je vendais une
toile ou que j'e désirais modifier quoi que ce soit fallait se taper une
somme de travail que je trouvais indûe. C'est pourquoi j'ai opté pour PHP et
MySQL.

Le dynamisme est en effet le principal avantage du PHP, une base de
donnée permet elle aussi d'augmenter le dynamisme...

Maintenant il y aura un livre de visiteurs, l'affichage des prix selon la
devise choisie par le visiteur, achat en ligne, envoi d'invitations et
d'annonces me concernant à ceux qui auront désiré recevoir de l'information,
un calendrier d'événements intéressants sur l'art et d'autres services que
j'ai en tête.

Tout ceci est possible, mais je ne vois toujours pas où l'utilisateur
risque d'avoir la possibilité d'introduire du code malicieux, si ce
n'est dans le livre d'utilisateurs.

Je pense que une fois que avez récupéré le texte de l'utilisateur, il
suffit de faire

<?php

$text = nl2br (addslashes (htmlentities ($_POST['text'])));

// Ne pas oublier de faire stripslashes () lors de l'affichage

?>

C'est, selon moi, largement suffisant.

Alors ce site, pas vraiment un site d'amateur par sa configuration, a besoin
de protection.

Tout site est amateur tant qu'on le considère en tant que tel. Tous les
sites que j'ai fait jusqu'à maintenant, je les ai toujours considérés,
comme résultats d'un amateur du PHP/xHTML/XML/XSLT/SQL, jamais
professionel, peu importe sa configuration.

Une première est Linux. Puis du filtrage de saisie de données.

Sous-entendez vous qu'un serveur Linux est plus *protégé* que MS
Windows? C'est un sujet à polémique sur lequel il, je le pense, ne faut
pas trop s'attarder, cependant, la remarque prête à sourrir ;).

Mais je ne sais absolument pas comment un vilain peut injecter des
"vilainetés" dans les champs de saisie. On m'a dit que ca se faisait mais on
n'a pu me dire comment. Alors je cherche.

Une des techniques les plus faciles à mettre en oeuvre, serait de coller
du javascript (malicieux) dans le champ de saisie, si l'on n'utilise pas
htmlentities (), le code sera interprêté par le navigateur à chaque
affichage.

Pour d'autres failles, je pense que les autres seront répondre d'une
façon bien plus éloquante que moi même.

Pour contrer ces attaques il faut savoir les perpétrer.

Pour contrer une attaque, il suffit de la comprendre, la perpêtrer
n'apporte que très peu de choses...

Tu en sais quelque chose ? dis-moi.

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:

http://groups-beta.google.com/group/fr.comp.securite/browse_frm/thread/1b8dd7e71340733d/90f48e144de8b57f?tvc=1&q=john+gallet#90f48e144de8b57f

Mes 2 centimes,

S.

Mais je ne sais absolument pas comment un vilain peut injecter des
"vilainetés" dans les champs de saisie. On m'a dit que ca se faisait mais
on
n'a pu me dire comment. Alors je cherche.

Quelques problèmes usuels
- Tu utilises une donnée saisie par un utilisateur pour générer une requête
SQL (par exemple "SELECT prix FROM tableaux WHERE id=$id"). La tu géneres du
texte qui sera interprété par ta base SQL. Donc il faut faire gaffe à ce que
vaut $id. Si tu attends un nombre, tu dois le vérifier, si tu attends une
chaine de caracteres, il faut utiliser la fonction qui va bien pour la
convertir au format SQL (principalement faire précéder les ' de )
- Tu fais un eval sur des données de l'utilisateur (gasp)
- Tu fais un include d'un fichier dynamiquement, avec un nom créé grace à
des données de l'utilisateur (genre include $file). Si tu as pas pris plein
de précautions, l'utilisateur pourra faire inclure par ton script n'importe
quel fichier (par exemple celui qui contient les mots de passe pour se
connecter à ta base de données...)

--
Vincent

Que magic quotes soit actif ou non, tu récupères de toutes facon une
simple

chaine

Alors si ce qui est entré en saisie n'est autre qu'une chaine, il n'y a
aucun moyen de causer des dommages de cette façon. Du point de vue du
vandale.

Disons que ca dépend de ce que tu fais avec ta chaine... Si tu ne fais que
l'afficher à l'utilisateur (la renvoyer au vandale potentiel), il n'y a
aucun risque de sécurité. Le seul risque est que sa chaine risque de
contenir du code HTML qui va modifier l'aspect qu'à ta page. La chaine ne
sera jamais interprétée par ton serveur.

htmlentities permet seulement d'éviter que quelqu'un entre des balises
html

dans ton code. En fait je pensais que tu parlais de ca comme injection...
Si

Alors seulement les balises html peuvent être interprétées dans les champs
de saisie.

Les balises HTML ne sont pas interprétées par le serveur, mais par le client
(ie ton vandal) pour donner le bon aspect à ta page.
Ce que tu ne veux pas, c'est que quelqu'un puisse faire générer par ton
serveur une page HTML invalide. Si tu inseres du texte que quelqu'un a tapé
dans ta page HTML, sans rien faire, il y a des chances pour que ca invalide
ton HTML (par exemple, si quelqu'un écrit 1 < 2, il faut que tu écrives 1
&lt; 2 dans la page HTML pour produire le bon résultat). Avec htmlentities,
tu transforme le texte en texte affichable en HTML.

J'écris un formulaire d'inscription pour les visiteurs. Le formulaire
complété j'affiche une page avec le résultat des champs de saisie et ceux
dont format entré ne correspond pas sont identifiés. Si un nom comprend
des
chiffres il est inscrit en rouge.

Donc pour me protéger de scripts malicieux je dois filtrer les champs. Je
le
fais avec des regex. L'affichage des champs ressemble à ceci:

echo $ligne = (eregi(un_filtre_quelconque,$champ_de_saisie) : "..... color

blue " ? " ..... color=red" ) . $champ_de_saisie ;

il faut faire

echo $line = (eregi(un_filtre_quelconque,$champ_de_saisie) : "..... color blue " ? " ..... color=red" ) . htmlentities($champ_de_saisie) ;

De cette façon je commande l'interprétation du script malicieux non ? et
je
cause mon propre malheur.

Non, $champ_de_saisie ne sera pas interprété par PHP. Il sera juste envoyé
au client.
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é).
Le seul problème (si on n'utilise pas htmlentities) c'est que si quelqu'un
écrit comme champ de saisie </body></html>, tu vas générer un document HTML
invalide, et le navigateur de celui qui regardera son site risque d'afficher
n'importe quoi (enfin, il affichera peut être pas le reste de la page, ou
s'il l'affiche, il l'affichera peut être n'importe comment).
Encore une fois, si quelqu'un écrit comme nom "Toto & compagnie", tu veux
générer <input type="text">Toto &amp; compagnie</input> (euh... désolé si
c'est pas du HTML valide). Ton script affiche <input type="text">Toto &
compagnie</input> (ce qui pour le coup n'est pas valide). Tu ne veux pas
enlever les éventuels scripts PHP de tes variables, tu veux juste les rendre
compatible avec la norme HTML. htmlentities fait ce travail pour toi
(remplacer les & par &amp; , les < par &lt; ...)

--
Vincent

Sebastian 'CrashandDie' Lauwers a dit le 21/03/2005 à 21:59:

$text = nl2br (addslashes (htmlentities ($_POST['text'])));

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.