Synthese "Pratiques de codage php et webapps"

John GALLET a dit le 26/06/2005 à 01:58:

Ce document est disponible sur http://www.saphirtech.com/securite.html ou
directement sur http://www.saphirtech.com/securite_web_dynamique.pdf

J'aime pas trop ce principe de "filtrer". Filtrer veut dire que les
données sont nécessairement mauvaises et qu'il faut essayer de se
débarasser des données malicieuses.
Il n'y a pas de mauvaises données. Y'a rien à filtrer du tout en fait,
c'est juste que les données, suivant leur système de transmission,
doivent être encodées différemment.
Les failles d'injection SQL et de XSS ne sont dues qu'à l'incompétence
des développeurs qui ne savent pas qu'il faut modifier les données selon
la situation.
Par exemple, pour afficher des données dans un document SGML ou XML, on
passe par htmlspecialchars(). C'est un truc de base et c'est évident. Et
pas de XSS possibles à l'horizon...

Je n'aime pas du tout cette fonction fx_filter qui revient à faire
exactement la même chose que magic_quotes_gpc, directive très contreversée.

Note : désolé de relancer le sujet.

Re,

J'aime pas trop ce principe de "filtrer".

Tu mets dessus l'étiquette que tu veux.

Filtrer veut dire que les
données sont nécessairement mauvaises et qu'il faut essayer de se
débarasser des données malicieuses.

Parce que ce n'est pas le cas ? J'envie ce monde de béatitude que tu
décris.

Il n'y a pas de mauvaises données. Y'a rien à filtrer du tout en fait,
c'est juste que les données, suivant leur système de transmission,
doivent être encodées différemment.

C'est une vision. Moi quand je vois arriver "rm -rf /" dans une variable
qui va être passée à la fonction exec(), je ne pense pas qu'il s'agisse
d'un problème d'encodage. Quand je vois arriver "1 OR 1=1" dans une PK
d'instruction DELETE, je ne pense pas que ce soit un problème
d'encodage.

Les failles d'injection SQL et de XSS ne sont dues qu'à l'incompétence
des développeurs qui ne savent pas qu'il faut modifier les données selon
la situation.

Personne n'a dit le contraire. C'est comme pour les variables non
initialisées / register_globals. D'ailleurs, toutes les failels de
sécurité sotn exclusivement des erreurs de codage ou de paramétrage, si
tu veux aller par là... Avec ça on a bien fait avancer le schmilblick.

Par exemple, pour afficher des données dans un document SGML ou XML, on
passe par htmlspecialchars().

Plutôt htmlentities() même.

C'est un truc de base et c'est évident.

Non, CE N'EST PAS évident pour tout le monde. Si ça l'était, il n'y
aurait plus d'attaques xss.

Je n'aime pas du tout cette fonction fx_filter qui revient à faire
exactement la même chose que magic_quotes_gpc, directive très contreversée.

A ma connaissance, il n'y a que deux méthodes pour éviter les injections
sql sur des strings( je ne parle pas des entiers) : ou utiliser les
prepared statements, ou échapper correctement les '. Si quelqu'un a une
autre solution, qu'il ne se prive pas, j'en suis entièrement à l'écoute.

Tu parles d'encodage, admettons ce point de vue; au lieu de faire de la
bidouille partout et surtout n'importe où, ce qui est le moyen le plus
sûr d'en oublier, ce que je propose là c'est un module qui est un point
d'entrée unique. Je conseille d'implémenter un module central, qui
valide les données selon toutes les attaques classiques et au passage en
tant que données fonctionnelles. Après tu l'implémentes comme tu veux.
Si tu as des prepared statements, ton "encodage" comme tu dis consistera
à virer les échappements de ' mises potentiellement mises par une
configuration non adaptée à ton code.

Note : désolé de relancer le sujet.
Puisque tu le fais, si tu en profitais pour apprendre à proposer des

solutions constructives et étayées factuellement au lieu de comme
d'habitude te borner à dire que les autres sont des cons et font de la
merde ? Tes solutions, toutes "évidentes" qu'elles soient, intéresseront
beaucoup de monde, j'en suis certain.

JG

John GALLET a dit le 26/06/2005 à 01:58:

Ce document est disponible sur http://www.saphirtech.com/securite.html
ou directement sur http://www.saphirtech.com/securite_web_dynamique.pdf

J'aime pas trop ce principe de "filtrer". Filtrer veut dire que les
données sont nécessairement mauvaises et qu'il faut essayer de se
débarasser des données malicieuses.

C'est exactement le cas. Il faut ** filtrer ** et donc éliminer ou <<
échapper >> ou << réinterpréter >> tout caractère présentant un danger
potentiel de par la signification qu'il peut avoir selon la plate-forme.

Il en va ainsi des '$', ''', '', etc dont le besoin réel en zone de
saisie est très rare.
Autant les éliminer la plupart du temps (zone de saisie textuelle) voire
les échapper ou les réinterpréter si la zone contient du texte devant
être transmis en tant que tel.

db

--

Courriel : usenet blas net

Dominique Blas wrote in message
<42c060a9$0$12672$626a14ce@news.free.fr>:

C'est exactement le cas. Il faut ** filtrer ** et donc éliminer ou <<
échapper >> ou << réinterpréter >> tout caractère présentant un danger
potentiel de par la signification qu'il peut avoir selon la plate-forme.

Il en va ainsi des '$', ''', '', etc dont le besoin réel en zone de
saisie est très rare.
Autant les éliminer la plupart du temps (zone de saisie textuelle) voire
les échapper ou les réinterpréter si la zone contient du texte devant
être transmis en tant que tel.

Attention les portes ouvertes...

Le premier et seul point indispensable, c'est de _comprendre_ ce qui se
passe avec le texte qu'on traite. Dès lors qu'on sait par quels parsers ne
chaîne donnée va successivement être interprétée, on peut prendre les
mesures exactement nécessaires.

Les fonctions de type filter_anything sont à mon avis néfastes parce
qu'elles incitent le programmeur à programmer au kilomètre sans réellement
comprendre ce qui se passe, alors qu'au final, elles risquent un jour ou
l'autre de laisser passer quelque chose de dangereux dans un cas atypique,
ou bien au contraire d'éliminer ou de déteriorer une chaîne dont on a besoin
qu'elle passe.

Bonjour,

Attention les portes ouvertes...
[...]

le programmeur à programmer au kilomètre sans réellement
comprendre ce qui se passe,

Dans la série portes ouvertes, je confirme : si l'interface chaise
clavier ne comprend pas ce qu'elle fait, on n'est pas rendus. Dans tous
les cas.

alors qu'au final, elles risquent un jour ou
l'autre de laisser passer quelque chose de dangereux dans un cas atypique,

Tout à fait d'accord avec cette remarque, si un développeur utilise le
module de filtrage sans savoir comment il fonctionne et pourquoi il faut
le faire, on va, un jour ou l'autre, à la cata (même si on y va moins
vite en utilisant bêtement qu'en ne faisant carrément rien). Il ne faut
effectivement pas rentrer dans la fausse sécurité en utilisant de
travers un module d'input sanitizing.

ou bien au contraire d'éliminer ou de déteriorer une chaîne dont on a besoin
qu'elle passe.

Ca c'est moins grave car ça relève du recettage normal de l'application.

a++;
JG

John GALLET <john.gallet@wanadoo.fr> :

ou bien au contraire d'éliminer ou de déteriorer une chaîne dont on a
besoin qu'elle passe.
Ca c'est moins grave car ça relève du recettage normal de l'application.

Oh non. A moins qu'il avertisse (dasnun fichier de log) des chaines qu'il
a flingué, moi je ne trouve pas ça normal ni tenable.

--
Miroir de logiciels libres http://www.etud-orleans.fr
Développement de logiciels libres http://aspo.rktmb.org/activites/developpement
Infogerance de serveur dédié http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)

Re,

ou bien au contraire d'éliminer ou de déteriorer une chaîne dont on a
besoin qu'elle passe.
Ca c'est moins grave car ça relève du recettage normal de l'application.

Oh non. A moins qu'il avertisse (dasnun fichier de log) des chaines qu'il
a flingué, moi je ne trouve pas ça normal ni tenable.

Comment on va le détecter ? Ou le cahier des charges précise que tel
type de chaîne DOIT passer et donc ça fait partie des tests 1) unitaires
2) de recettage, ou le cdc ne dit rien donc on a pas à l'accepter.

Rien n'empêche de loguer les changements, mais il va falloir le faire
intelligement. Comment je différencie le changement du nom de famille
"d'Andorre" vers "d'Andorre" d'une tentative d'injection sql ? (en
utilisant les prepared statements, bon d'accord).

Que la protection soit faite par un seul module central ou par
watt-milliards de fonctions/méthodes, on aura le même problème :
détecter un changement entre la chaîne d'origine et la chaîne tripotée,
c'est pas difficile, mais dès lors qu'on va appliquer une transformation
en entitées html et un échappement des ' je crains d'avoir du mal à ne
pas logguer 70% des données reçues.

J'aimerais bien appliquer ce bon principe (être averti qu'une donnée
légitime s'est fait sabrer à tord) et je suis très intéressé par toute
solution pour le faire au run-time, mais là à froid, je ne vois pas
comment.

JG

Dominique Blas wrote:

C'est exactement le cas. Il faut ** filtrer ** et donc éliminer ou <<
échapper >> ou << réinterpréter >> tout caractère présentant un danger
potentiel de par la signification qu'il peut avoir selon la plate-forme.

Il en va ainsi des '$', ''', '', etc dont le besoin réel en zone de
saisie est très rare. Autant les éliminer...

pendant que tu y es, tu devrais imposer aux poules de pondre des oeufs
carrés. pourquoi par exemple veux-tu corrompre les noms ou adresses
comportant des apostrophes ?

--
P'tit Marcel
apostrophant

John GALLET wrote:

Il y a quelques mois je m'étais engagé à faire une synthèse du thread
"Pratiques de codage php et webapps" <41A1C3C1.22FF0946@wanadoo.fr>

J'y ai passé trois WE complets, mais c'est fini.

Ce document est disponible sur http://www.saphirtech.com/securite.html ou
directement sur http://www.saphirtech.com/securite_web_dynamique.pdf

tout d'abord je verse à l'auteur de ce document une montagne de gratitude
pour ce travail assez complet et lisible par tout le monde. Produire
un tel document c'est implicitement se mettre en position de vulnerabilité.
Ce document ayant une forte dominance pour le langage php, il conviendrait
de le soumettre au groupe des utilisateurs php pour complements sans parler
d'approbation. Il existe deja un livre blanc.


Les risques sont assez bien abordés et expliqués. Ils semblent exhautifs.
Le passage sur le XSS ne m'a pas parus tres clair. Je ne suis pas tres
éclairé sur ce sujet c'est normal ...


Sauf erreur de pa mart, le point le plus important sur le XSS,
c'est le mot CROSS. Cela signifie qu'il y a une attaque externe realisée
par injection de code malicieux dans les données (souvent en database).
Cette technique regroupe plusieurs principes assez différents mais
faisant toujours appel à un lien externe. C'est par ce lien externe
que seront transmis des informations a caractere confidentiel
qui n'auraient pas du l'etre. Potentiellement un administrateur de
site lorsqu'il se connaitre véhicule avec sa connexion des informations;
ce sont ces memes informations de connexion qui sont aussi transmisses
au site malicieux. Ce peut-etre tout simplement une clé d'acces (un cookie)
et grace a cette clé, le site malicieux peut venir "jardiner" dans les
bases de données et peut-etre aussi dans les fichiers.

C'est "ma" vision des choses, lisant assez mal l'anglais, je ne crois
pas que je soit tres eloigné de la realité. Peut-etre que je n'ai
decris qu'une partie du monde XSS.


La solution de filtrage proposée par John est suffisante pour demarrer
un site. Il peut-etre convenable de decrire les données manipulée
sous forme logique et de proceder a du filtrage systématique. ex
d'implementation :

$person = array(

'nom' = array(
'type' => 'string'
'default => ''
...
),
'age' => array(
'type' => 'integer'
'default => 0
...
),
);


* la description peut etre realisée dans des langages plus universels,
mais le principe reste le meme (xml, IDL ...)

* lors de la manipulation des entrées en base de données, il suffit
de disposer de fonctions (ou methodes) exploitant la description
des enregistrement et le tour est joué.

* c'est implementé en php avec des classes de type DAO.


encore une fois "BRAVO" John.

On Sat, 25 Jun 2005 23:58:12 +0000, John GALLET wrote:

Il y a quelques mois je m'étais engagé à faire une synthèse du thread
"Pratiques de codage php et webapps" <41A1C3C1.22FF0946@wanadoo.fr>

Quelques remarques :

- page 11, utilisation de file_exists() : sage précaution de ne pas faire
confiance à cette fonction. Comme l'a montré Simon Maréchal au SSTIC en
début de mois, file_exists() marche à présent (PHP5) avec ftp:// (mais
toujours pas en http://).

- page 14 : vérification du type de fichier. Tu parles de la commande
'file', mais le problème se pose aussi avec les fonctions PHP de
récupération de la largeur/hauteur d'une image.

- page 21 : liste des fonctions dangereuses. Tu listes eval(), exec(),
passthru(), system(), shell_exec(). Il manque (de tête) popen() et
proc_open(). Y a pas aussi une feinte (via un modificateur) avec les
expressions régulières ?


Nicob