testeur de securite

Bonjour,

Lors de la livraison d'un serveur WEB (WAMP) à mon hébergeur, ce
dernier a passé l'ensemble de mes scripts php, à un scanneur de
failles de sécurité (surement un outil professionnel payant). Ce
dernier a d'ailleurs relevé quelques anomalies. Existe-t'il de tels
outils libres pour les quidams comme moi ?

Si ce n'est déjà fait, je pense qu'une question dans fr.comp.securite
aurait plus de chance d'avoir des réponses.

Maintenant soyons réalistes: si ce genre de trucs fonctionnaient, il n'y
aurait plus de failles, or c'est loin d'être le cas. A part un audit (en
particulier du code source, plutôt qu'en aveugle), je ne connais pas
grand chose de fiable. Si je reprends rapidement les grandes catégories
de failles que j'avais répertoriées, je ne vois pas trop comment les
détecter automatiquement (au hasard, une XSS stockée via la partie
publique qui s'active dans la partie d'admin...).

Pour ma culture perso, je serais curieux de savoir quel genre
"d'anomalies" ça peut bien trouver.

a++;
JG

John GALLET <john.gallet@wanadoo.fr>, le dim. 27 juil. 2008
20:32:02, écrivait ceci:

Salut,

Si ce n'est déjà fait, je pense qu'une question dans
fr.comp.securite aurait plus de chance d'avoir des réponses.

J'y avais pensé, mais ce sont bien les erreurs de programmation en php
qui m'interesse.

Maintenant soyons réalistes: si ce genre de trucs fonctionnaient,
il n'y aurait plus de failles, or c'est loin d'être le cas. A part
un audit (en particulier du code source, plutôt qu'en aveugle), je
ne connais pas grand chose de fiable. Si je reprends rapidement
les grandes catégories de failles que j'avais répertoriées, je ne
vois pas trop comment les détecter automatiquement (au hasard, une
XSS stockée via la partie publique qui s'active dans la partie
d'admin...).

De la même façon que les antivirus, ils ne sont "efficaces" que pour la
détection des signatures connues. Ou bien comme les sites de controle
w3c. Il existe aussi des programmes pour script kiddies, clé en main,
qui recherchent les anomalies de configurations....
Il est hors de question de tout détecter, mais de controler une liste
de failles connues. (De la même façon qu'un correcteur d'orthographe
permet de trouver une erreur de frappe).

Pour ma culture perso, je serais curieux de savoir quel genre
"d'anomalies" ça peut bien trouver.

Hélàs je n'ai pas eu un long contact avec ce rapport (c'est d'ailleurs
pour ça que j'ai posté, pour que je puisse explorer moi même).
Il me semble qu'il avait détecté, entre autre, la possibilité
d'injecter un texte dans une variable de session qui désignait le nom
d'un fichier log.

En fait, au vu des réponses, je crois qu'il ne reste que la méthode
classique : utiliser des listes de failles (t'as pas ta liste sous le
coude par hasard ? :-) ), et vérifier si elles s'appliquent.

Merci pour ta réponse en tout cas

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

--2036061576-359067700-1217233763=:3137
Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

20:32:02, écrivait ceci:

Mime ?

--2036061576-359067700-1217233763=:3137--

Wouf.


On Mon, 28 Jul 2008, John GALLET wrote:

20:32:02, écrivait ceci:

Mime ?

Re,

Si ce n'est déjà fait, je pense qu'une question dans
fr.comp.securite aurait plus de chance d'avoir des réponses.

J'y avais pensé, mais ce sont bien les erreurs de programmation en php
qui m'interesse.

Je ne connais pas d'analyseur automatique de code php, seulement des
scanneurs qui testent le comportement de l'application.

De la même façon que les antivirus, ils ne sont "efficaces" que pour la
détection des signatures connues.

J'ai du mal à voir ce que peut bien être une "signature" dans du code
source. Pour avoir essayé moi même de faire des recherches systématisées
lors de certains audits (récemment, un paquet de m***e de plus de 2500
fichiers écrit via MXKart, le soft d'Interakt, plugin générateur de code
pour Dreamweaver), je pense qu'on peut écrire un programme qui va vérifier
les injections possibles de variables dans les chemins des includes (ce
type de truc génère des milliers d'include dynamiques, dans des boucles,
un vrai bohneur), c'est uniquement suivre la source de la donnée. On peut
aussi avoir un signal d'alarme sur des fonctions "dangereuses" du genre
exec/system ou import_request_variables, mais à part ça...

Ou bien comme les sites de controle w3c.

Ce n'est pas la même chose, là il "suffit" de faire coller la DTD au
résultat, c'est du parsing pur, ou de suivre un lien et de faire un HEAD
pour lire la réponse. C'est syntaxique avec une norme forte.

Il existe aussi des programmes pour script kiddies, clé en main,
qui recherchent les anomalies de configurations....

Ca, oui, mais c'est bien avec stimulation en aveugle, pas en analyse
syntaxique automatisée, je n'en connais pas.

Il me semble qu'il avait détecté, entre autre, la possibilité
d'injecter un texte dans une variable de session qui désignait le nom
d'un fichier log.

Pas inintéressant en soit, même s'il faut encore l'exploiter, ça peut
sentir le roussi selon la config locale et l'injection elle même.

En fait, au vu des réponses, je crois qu'il ne reste que la méthode
classique : utiliser des listes de failles (t'as pas ta liste sous le
coude par hasard ? :-) ), et vérifier si elles s'appliquent.

J'ai écrit une petite galerie des horreurs dans un PDF dispo sur
http://www.saphirtech.fr/securite.html

Ca date un peu, mais je n'ai rien vu de révolutionnaire arriver depuis
concernant PHP en lui même. On peut ajouter des choses dangereures côté
client (les PDF dans la liste des fichiers dangereux à accepter en upload
par exemples, avec leur cochonnerie de JS embarqué) mais je n'ai rien vu
de radicalement différent côté serveur. Bien entendu, le paragraphe sur
"c'est valide grâce à javascript" est encore plus vrai avec "ajax".

Des papiers commencent à circuler sur les nouvelles conneries liées au
stockage côté client de html 5, et ça va être rigolo probablement, mais
pour le moment on y est pas encore.

a++;
JG

John GALLET <john.gallet@wanadoo.fr>, le lun. 28 juil. 2008
13:18:16, écrivait ceci:

Re,

Je ne connais pas d'analyseur automatique de code php, seulement
des scanneurs qui testent le comportement de l'application.

En fait, tu as raison. C'est plus le principe du scan de comportement,
qui m'interesse. Je me suis donc mal exprimé. (d'ailleurs j'imagine un
scanneur qui regarderait certains de mes codes :-$ )

De la même façon que les antivirus, ils ne sont "efficaces" que
pour la détection des signatures connues.

J'ai du mal à voir ce que peut bien être une "signature" dans du
code source.

Je citais cette méthode, uniquement pour illustrer le fait qu'un
antivirus ne peut contrôler que ce qu'il connait (les signatures ou les
codes heuristiques)

Pour avoir essayé moi même de faire des recherches
systématisées lors de certains audits (récemment, un paquet de
m***e de plus de 2500 fichiers écrit via MXKart, le soft
d'Interakt, plugin générateur de code pour Dreamweaver), je pense
qu'on peut écrire un programme qui va vérifier les injections
possibles de variables dans les chemins des includes (ce type de
truc génère des milliers d'include dynamiques, dans des boucles,
un vrai bohneur), c'est uniquement suivre la source de la donnée.
On peut aussi avoir un signal d'alarme sur des fonctions
"dangereuses" du genre exec/system ou import_request_variables,
mais à part ça...

C'est déjà bien d'avoir ça. Même au niveau newbee, ça permet de ne pas
prendre de mauvaises habitudes.

J'ai écrit une petite galerie des horreurs dans un PDF dispo sur
http://www.saphirtech.fr/securite.html

Ca date un peu, mais je n'ai rien vu de révolutionnaire arriver
depuis concernant PHP en lui même. On peut ajouter des choses
dangereures côté client (les PDF dans la liste des fichiers
dangereux à accepter en upload par exemples, avec leur cochonnerie
de JS embarqué) mais je n'ai rien vu de radicalement différent
côté serveur. Bien entendu, le paragraphe sur "c'est valide grâce
à javascript" est encore plus vrai avec "ajax".

Des papiers commencent à circuler sur les nouvelles conneries
liées au stockage côté client de html 5, et ça va être rigolo
probablement, mais pour le moment on y est pas encore.

Oui. J'avais déjà vu cette page, et m'en était fortement inspiré, le
jour où l'on m'a mis un projet php dans les mains. Je profite que l'on
soit en "conversation" pour t'en remercier : je suis passé pour moins
profane que je l'était réellement :-).

Re,

En fait, tu as raison. C'est plus le principe du scan de comportement,
qui m'interesse. Je me suis donc mal exprimé. (d'ailleurs j'imagine un
scanneur qui regarderait certains de mes codes :-$ )

Sur le fond, c'est bien la manière dont je commence un audit, à grand coup
de find -exec grep MOT_CLEF par exemple pour voir si on se sert des
sessions natives de php, des cookies, si on tripote _GET/_POST ou
seulement _REQUEST, si on le fait avec une seule fonction d'accès etc. Il
y a quand même des mots clefs réservés du langage PHP lui même qui
*peuvent* servir de "signature", mais ça risque d'être assez limité.

Je n'ai clairement pas le temps d'écrire un tel outil, bien qu'il me
serait utile d'ailleurs, mais si quelqu'un a envie de pousser la réflexion
sur un algo possible, je veux bien détailler un peu plus certaines
méthodes que j'applique (manuellement et laborieusement).

On pourrait aussi automatiser le croisement entre les répertoires protégés
par un .htaccess "deny all" et les extensions ésotériques non parsées
(.inc au hasard), avec un warning "non sécurisé si httpd!=apache", trouver
les .old et autres ~bck contenant des chaînes du style "password".

Bref, ce type d'outil pourrait exister, mais si c'est le cas je n'en
connais pas.

J'ai écrit une petite galerie des horreurs dans un PDF dispo sur
http://www.saphirtech.fr/securite.html

Oui. J'avais déjà vu cette page, et m'en était fortement inspiré, le
jour où l'on m'a mis un projet php dans les mains. Je profite que l'on
soit en "conversation" pour t'en remercier : je suis passé pour moins
profane que je l'était réellement :-).

Content que ça ait été utile.

Le but principal de ce document est de forcer le lecteur à se poser des
questions sur sa compréhension de la situation, quel que soit son niveau.
Méfie toi en revanche que certaines opinions qui y sont exprimées ne sont
pas "à la mode", quand ce n'est pas carrément à contre-courant des
(soit-disant) "best-practices" (comme qu'ils disent).

a++;
JG