tout d'abord je verse à l'auteur de ce document une montagne de gratitude Je vais rougir ;-)
pour ce travail assez complet et lisible par tout le monde. C'est bien le but : que le débutant moyen applique des règles simples
pour éviter les horreurs les plus classiques.
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.
De quel groupe parles-tu ? Si c'est phpsec.org, j'ai proposé à Chris Shiflett de faire une traduction, mais il m'a indiqué avoir déjà quelqu'un. Si tu parles d'un PUG français, il n'y en a qu'un à ma connaissance, l'afup, dont j'ai co-rédigé les statuts et tenu le poste de Trésorier du premier Bureau, et je n'ai pas besoin d'eux pour valider quoi que ce soit en PHP (aïe! mes chevilles). Si j'ai laissé le fu2 sur fcs, c'est parce que les principes que je décris sont indépendants de la plateforme (sauf indications explicites).
Le passage sur le XSS ne m'a pas parus tres clair. Ok, je vais le relire. On m'a aussi signalé une ânerie de numérotation
dans les paragraphes.
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.
A ma connaissance c'est bien ça mais tout ce que tu as décrit là est indiqué dans ma prose. Enfin, c'est ce que j'ai voulu en expliquer. Donc ou tu as sauté le paragraphe, ou c'est pas clair, ou c'est limité à une phrase paumée (plus probablement, au fin fond d'une relative d'une phrase à tiroirs, il m'arrive régulièrement de ne plus savoir de quoi que j'cause après trois lignes, on va bientôt m'appeler le Desproges de l'informatique).
La solution de filtrage proposée par John est suffisante pour demarrer un site. En implémentant les différents types fonctionnels que je donne why not.
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 : * la description peut etre realisée dans des langages plus universels, mais le principe reste le meme (xml, IDL ...)
C'est ce que j'indique en parlant "d'industrialisation" et d'ORM. Mais tu as raison de le rappeler, un point présent dans le thread d'origine que je n'ai pas nécessairement assez retranscrit est le besoin de faire simple et centralisé (pour en pas s'auto-emmêler les pinceaux et ne pas en oublier dans un coin).
* 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é.
Si tu pars dans des descripturs de données, oui, tu peux totalement automatiser tout ça, y compris aussi le côté obligatoire/facultatif de la donnée, voire le message d'erreur à afficher si une donnée obligatoire est absente ou un descriptif d'aide contextuelle affichée en pop JS, etc... Personnellement, je n'utilise pas de descripteurs de données au run-time, mais j'utilise parfois des descripteurs pour alimenter des générateurs de code qui me font toute la partie fastidieuse, et je n'ai qu'à faire un copié collé du code PHP résultant.
encore une fois "BRAVO" John. Merci, ce fût long et pénible, mais je n'ai pas trouvé un document
unique et simple abordant le sujet sous un angle purement web-apps, d'où le thread en novembre. Depuis quelques publications ont eut lieu en anglais (avec des choses sur lesquelles je ne suis pas d'accord d'ailleurs).
a++; JG
Bonjour,
tout d'abord je verse à l'auteur de ce document une montagne de gratitude
Je vais rougir ;-)
pour ce travail assez complet et lisible par tout le monde.
C'est bien le but : que le débutant moyen applique des règles simples
pour éviter les horreurs les plus classiques.
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.
De quel groupe parles-tu ? Si c'est phpsec.org, j'ai proposé à Chris
Shiflett de faire une traduction, mais il m'a indiqué avoir déjà
quelqu'un. Si tu parles d'un PUG français, il n'y en a qu'un à ma
connaissance, l'afup, dont j'ai co-rédigé les statuts et tenu le poste
de Trésorier du premier Bureau, et je n'ai pas besoin d'eux pour valider
quoi que ce soit en PHP (aïe! mes chevilles). Si j'ai laissé le fu2 sur
fcs, c'est parce que les principes que je décris sont indépendants de la
plateforme (sauf indications explicites).
Le passage sur le XSS ne m'a pas parus tres clair.
Ok, je vais le relire. On m'a aussi signalé une ânerie de numérotation
dans les paragraphes.
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.
A ma connaissance c'est bien ça mais tout ce que tu as décrit là est
indiqué dans ma prose. Enfin, c'est ce que j'ai voulu en expliquer. Donc
ou tu as sauté le paragraphe, ou c'est pas clair, ou c'est limité à une
phrase paumée (plus probablement, au fin fond d'une relative d'une
phrase à tiroirs, il m'arrive régulièrement de ne plus savoir de quoi
que j'cause après trois lignes, on va bientôt m'appeler le Desproges de
l'informatique).
La solution de filtrage proposée par John est suffisante pour demarrer
un site.
En implémentant les différents types fonctionnels que je donne why not.
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 :
* la description peut etre realisée dans des langages plus universels,
mais le principe reste le meme (xml, IDL ...)
C'est ce que j'indique en parlant "d'industrialisation" et d'ORM. Mais
tu as raison de le rappeler, un point présent dans le thread d'origine
que je n'ai pas nécessairement assez retranscrit est le besoin de faire
simple et centralisé (pour en pas s'auto-emmêler les pinceaux et ne pas
en oublier dans un coin).
* 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é.
Si tu pars dans des descripturs de données, oui, tu peux totalement
automatiser tout ça, y compris aussi le côté obligatoire/facultatif de
la donnée, voire le message d'erreur à afficher si une donnée
obligatoire est absente ou un descriptif d'aide contextuelle affichée en
pop JS, etc...
Personnellement, je n'utilise pas de descripteurs de données au
run-time, mais j'utilise parfois des descripteurs pour alimenter des
générateurs de code qui me font toute la partie fastidieuse, et je n'ai
qu'à faire un copié collé du code PHP résultant.
encore une fois "BRAVO" John.
Merci, ce fût long et pénible, mais je n'ai pas trouvé un document
unique et simple abordant le sujet sous un angle purement web-apps, d'où
le thread en novembre. Depuis quelques publications ont eut lieu en
anglais (avec des choses sur lesquelles je ne suis pas d'accord
d'ailleurs).
tout d'abord je verse à l'auteur de ce document une montagne de gratitude Je vais rougir ;-)
pour ce travail assez complet et lisible par tout le monde. C'est bien le but : que le débutant moyen applique des règles simples
pour éviter les horreurs les plus classiques.
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.
De quel groupe parles-tu ? Si c'est phpsec.org, j'ai proposé à Chris Shiflett de faire une traduction, mais il m'a indiqué avoir déjà quelqu'un. Si tu parles d'un PUG français, il n'y en a qu'un à ma connaissance, l'afup, dont j'ai co-rédigé les statuts et tenu le poste de Trésorier du premier Bureau, et je n'ai pas besoin d'eux pour valider quoi que ce soit en PHP (aïe! mes chevilles). Si j'ai laissé le fu2 sur fcs, c'est parce que les principes que je décris sont indépendants de la plateforme (sauf indications explicites).
Le passage sur le XSS ne m'a pas parus tres clair. Ok, je vais le relire. On m'a aussi signalé une ânerie de numérotation
dans les paragraphes.
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.
A ma connaissance c'est bien ça mais tout ce que tu as décrit là est indiqué dans ma prose. Enfin, c'est ce que j'ai voulu en expliquer. Donc ou tu as sauté le paragraphe, ou c'est pas clair, ou c'est limité à une phrase paumée (plus probablement, au fin fond d'une relative d'une phrase à tiroirs, il m'arrive régulièrement de ne plus savoir de quoi que j'cause après trois lignes, on va bientôt m'appeler le Desproges de l'informatique).
La solution de filtrage proposée par John est suffisante pour demarrer un site. En implémentant les différents types fonctionnels que je donne why not.
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 : * la description peut etre realisée dans des langages plus universels, mais le principe reste le meme (xml, IDL ...)
C'est ce que j'indique en parlant "d'industrialisation" et d'ORM. Mais tu as raison de le rappeler, un point présent dans le thread d'origine que je n'ai pas nécessairement assez retranscrit est le besoin de faire simple et centralisé (pour en pas s'auto-emmêler les pinceaux et ne pas en oublier dans un coin).
* 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é.
Si tu pars dans des descripturs de données, oui, tu peux totalement automatiser tout ça, y compris aussi le côté obligatoire/facultatif de la donnée, voire le message d'erreur à afficher si une donnée obligatoire est absente ou un descriptif d'aide contextuelle affichée en pop JS, etc... Personnellement, je n'utilise pas de descripteurs de données au run-time, mais j'utilise parfois des descripteurs pour alimenter des générateurs de code qui me font toute la partie fastidieuse, et je n'ai qu'à faire un copié collé du code PHP résultant.
encore une fois "BRAVO" John. Merci, ce fût long et pénible, mais je n'ai pas trouvé un document
unique et simple abordant le sujet sous un angle purement web-apps, d'où le thread en novembre. Depuis quelques publications ont eut lieu en anglais (avec des choses sur lesquelles je ne suis pas d'accord d'ailleurs).
a++; JG
Nicob
On Wed, 29 Jun 2005 15:24:39 +0000, Nicob wrote:
Y a pas aussi une feinte (via un modificateur) avec les expressions régulières ?
Mea cupla, c'est de l'exécution de PHP, pas un appel système.
Extrait de l'advisory phpBB du jour :
=================================================================== The highlighting code uses the preg_replace() function on line 1110 in viewtopic.php. It uses the special modifier "e" which causes PHP to evaluate the replacement string as PHP code. Below is a PHP code example of what actually happens:
This causes PHP to execute the phpinfo() function. Usage of the preg_replace special modifier "e" should be avoided if possible. ===================================================================
Nicob
On Wed, 29 Jun 2005 15:24:39 +0000, Nicob wrote:
Y a pas aussi une feinte (via un modificateur) avec les
expressions régulières ?
Mea cupla, c'est de l'exécution de PHP, pas un appel système.
Extrait de l'advisory phpBB du jour :
=================================================================== The highlighting code uses the preg_replace() function on line 1110
in viewtopic.php. It uses the special modifier "e" which causes PHP
to evaluate the replacement string as PHP code. Below is a PHP code
example of what actually happens:
This causes PHP to execute the phpinfo() function. Usage of the
preg_replace special modifier "e" should be avoided if possible.
===================================================================
Y a pas aussi une feinte (via un modificateur) avec les expressions régulières ?
Mea cupla, c'est de l'exécution de PHP, pas un appel système.
Extrait de l'advisory phpBB du jour :
=================================================================== The highlighting code uses the preg_replace() function on line 1110 in viewtopic.php. It uses the special modifier "e" which causes PHP to evaluate the replacement string as PHP code. Below is a PHP code example of what actually happens:
This causes PHP to execute the phpinfo() function. Usage of the preg_replace special modifier "e" should be avoided if possible. ===================================================================
Nicob
Simon Marechal
Nicob wrote:
- 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 ?
preg_replace avec le flag "e"
Nicob wrote:
- 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 ?
- 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 ?
preg_replace avec le flag "e"
John GALLET
Bonjour,
- 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://).
Merci pour cette information, la doc de php est vraiment obscure à ce sujet et ça m'avait mis la puce à l'oreille, leurs trucs sur les streams : ça puait la faille potentielle à plein nez. Je n'ai toujours pas téléchargé php5 (va falloir que j'y mette un jour, pour faire des tests à la c.. de ce genre) donc pas pu tester.
- 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. Bonne remarque, ça va mieux en le précisant.
Tiens en revanche j'y pense, faudra que je voie si on peut se protéger en recopiant l'image via une fonction de la GD lib qui aurait une petite chance de lire *toute* l'image et pas seulement les premiers octets. Par exemple avec un getcopyresampled à la même taille/résolution. M'étonnerait mais bon.
- page 21 : liste des fonctions dangereuses. Tu listes eval(), exec(), passthru(), system(), shell_exec(). Il manque (de tête) popen() et proc_open(). Ok.
Y a pas aussi une feinte (via un modificateur) avec les expressions régulières ?
Si, le modificateur /e qui permet d'évaluer, c'est justement la dernière faille (en date, parce qu'on a pas fini d'être emmerdés par cette application) dans phpBB, j'ai vu passé ça sur security focus ce matin même.
C'est tellement DEBILE que le langage propose cette fonctionnalité (comme les ` back-ticks d'ailleurs) que je n'y aurais jamais pensé. En revanche,il faut que je prenne le temps de vérifier si c'est une connerie nouvelle avec PHP ou si c'est emprunté d'un autre langage.
Merci pour ces remarques. JG
Bonjour,
- 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://).
Merci pour cette information, la doc de php est vraiment obscure à ce
sujet et ça m'avait mis la puce à l'oreille, leurs trucs sur les streams
: ça puait la faille potentielle à plein nez. Je n'ai toujours pas
téléchargé php5 (va falloir que j'y mette un jour, pour faire des tests
à la c.. de ce genre) donc pas pu tester.
- 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.
Bonne remarque, ça va mieux en le précisant.
Tiens en revanche j'y pense, faudra que je voie si on peut se protéger
en recopiant l'image via une fonction de la GD lib qui aurait une petite
chance de lire *toute* l'image et pas seulement les premiers octets. Par
exemple avec un getcopyresampled à la même taille/résolution.
M'étonnerait mais bon.
- page 21 : liste des fonctions dangereuses. Tu listes eval(), exec(),
passthru(), system(), shell_exec(). Il manque (de tête) popen() et
proc_open().
Ok.
Y a pas aussi une feinte (via un modificateur) avec les
expressions régulières ?
Si, le modificateur /e qui permet d'évaluer, c'est justement la dernière
faille (en date, parce qu'on a pas fini d'être emmerdés par cette
application) dans phpBB, j'ai vu passé ça sur security focus ce matin
même.
C'est tellement DEBILE que le langage propose cette fonctionnalité
(comme les ` back-ticks d'ailleurs) que je n'y aurais jamais pensé.
En revanche,il faut que je prenne le temps de vérifier si c'est une
connerie nouvelle avec PHP ou si c'est emprunté d'un autre langage.
- 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://).
Merci pour cette information, la doc de php est vraiment obscure à ce sujet et ça m'avait mis la puce à l'oreille, leurs trucs sur les streams : ça puait la faille potentielle à plein nez. Je n'ai toujours pas téléchargé php5 (va falloir que j'y mette un jour, pour faire des tests à la c.. de ce genre) donc pas pu tester.
- 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. Bonne remarque, ça va mieux en le précisant.
Tiens en revanche j'y pense, faudra que je voie si on peut se protéger en recopiant l'image via une fonction de la GD lib qui aurait une petite chance de lire *toute* l'image et pas seulement les premiers octets. Par exemple avec un getcopyresampled à la même taille/résolution. M'étonnerait mais bon.
- page 21 : liste des fonctions dangereuses. Tu listes eval(), exec(), passthru(), system(), shell_exec(). Il manque (de tête) popen() et proc_open(). Ok.
Y a pas aussi une feinte (via un modificateur) avec les expressions régulières ?
Si, le modificateur /e qui permet d'évaluer, c'est justement la dernière faille (en date, parce qu'on a pas fini d'être emmerdés par cette application) dans phpBB, j'ai vu passé ça sur security focus ce matin même.
C'est tellement DEBILE que le langage propose cette fonctionnalité (comme les ` back-ticks d'ailleurs) que je n'y aurais jamais pensé. En revanche,il faut que je prenne le temps de vérifier si c'est une connerie nouvelle avec PHP ou si c'est emprunté d'un autre langage.
Merci pour ces remarques. JG
Simon Marechal
John GALLET wrote:
C'est tellement DEBILE que le langage propose cette fonctionnalité (comme les ` back-ticks d'ailleurs) que je n'y aurais jamais pensé. En revanche,il faut que je prenne le temps de vérifier si c'est une connerie nouvelle avec PHP ou si c'est emprunté d'un autre langage.
A mon avis il y a des choses bien plus idiotes, comme les url wrappers, le global_register, etc. Le flag "e" est bien utile et est présent en perl (comme leur nom l'indique les fonctions preg_* viennent de perl). Le seul moyen d'émuler cette fonctionnalité est je pense un split() suivi d'un array_map(), mais ça ne fait pas vraiment la même chose.
En même temps, il est vrai que c'est surtout un outil de golfeur.
John GALLET wrote:
C'est tellement DEBILE que le langage propose cette fonctionnalité
(comme les ` back-ticks d'ailleurs) que je n'y aurais jamais pensé.
En revanche,il faut que je prenne le temps de vérifier si c'est une
connerie nouvelle avec PHP ou si c'est emprunté d'un autre langage.
A mon avis il y a des choses bien plus idiotes, comme les url wrappers,
le global_register, etc. Le flag "e" est bien utile et est présent en
perl (comme leur nom l'indique les fonctions preg_* viennent de perl).
Le seul moyen d'émuler cette fonctionnalité est je pense un split()
suivi d'un array_map(), mais ça ne fait pas vraiment la même chose.
En même temps, il est vrai que c'est surtout un outil de golfeur.
C'est tellement DEBILE que le langage propose cette fonctionnalité (comme les ` back-ticks d'ailleurs) que je n'y aurais jamais pensé. En revanche,il faut que je prenne le temps de vérifier si c'est une connerie nouvelle avec PHP ou si c'est emprunté d'un autre langage.
A mon avis il y a des choses bien plus idiotes, comme les url wrappers, le global_register, etc. Le flag "e" est bien utile et est présent en perl (comme leur nom l'indique les fonctions preg_* viennent de perl). Le seul moyen d'émuler cette fonctionnalité est je pense un split() suivi d'un array_map(), mais ça ne fait pas vraiment la même chose.
En même temps, il est vrai que c'est surtout un outil de golfeur.
Ravach0l
Il m'est arrive de voir des scripts ou le developpeur ouvrait un fichier avec fopen($fichier); et ou il lisait ensuite les url d'image depuis ce fichier pour l'afficher. Les url etaient stocke au format texte. Les url ainsi recupere etait mise dans des balise <img>. Il suffisait de filtrer pour reconstituer le contenue de n'importe quelle fichier.
Il m'est arrive de voir des scripts ou le developpeur ouvrait un fichier
avec fopen($fichier); et ou il lisait ensuite les url d'image depuis ce
fichier pour l'afficher. Les url etaient stocke au format texte. Les url
ainsi recupere etait mise dans des balise <img>. Il suffisait de filtrer
pour reconstituer le contenue de n'importe quelle fichier.
Il m'est arrive de voir des scripts ou le developpeur ouvrait un fichier avec fopen($fichier); et ou il lisait ensuite les url d'image depuis ce fichier pour l'afficher. Les url etaient stocke au format texte. Les url ainsi recupere etait mise dans des balise <img>. Il suffisait de filtrer pour reconstituer le contenue de n'importe quelle fichier.
