Discussion :

[Mat_F]

Bonjour,

Je suis en train de développer de petits modules CGI.
Je précise qu'il n'y a aucune connexion à une quelconque base de données.

Apparamment il y a pas mal de risques au niveau de la sécurité avec Perl, liés à la possibilité qu'un utilisateur puisse "hacker" une page, genre pour exécuter des commandes (genre effacer un fichier) à travers un formulaire.

Qqn. aurait-il/elle la gentilesse de m'expliquer:

1. comment s'y prend-on pour hacker une page (exemples bienvenus)
2. comment s'en prémunir au mieux.

Comme ça peut être assez compliqué ou long à expliquer, un lien vers de la doc pertinente est aussi bienvenu (genre si possible pas un lien sur "apprendre à programmer avec Perl" ;-)

Voilà,

Merci d'avance

[Jedai]

Tu devrais commencer par lire attentivement la documentation du module CGI (qui est la bonne façon de faire du CGI en Perl aujourd'hui, tiens toi à bonne distance de tout script qui utiliserait encore cgi-lib ou autre horreur des temps antiques...) et de DBI (particulièrement la partie sur les placeholders, qui t'éviteront toute injection SQL) ainsi que la section de la doc sur le mode tainted.

En général, et surtout si tu utilises le mode tainted, Perl est bien plus résistant aux attaques que ses concurrents (je pense surtout à PHP ici, qui est une vraie passoire), sa mauvaise réputation vient surtout du temps où d'innombrables programmeurs d'un jour se "créaient" "leur" page CGI en collant ensemble des bouts de code divers trouvés sur la toile et utilisant l'antique cgi-lib. Le plus important c'est de toujours rester prudent par rapport à son code.

Je vais te donner un petit exemple débile des failles qu'on peut trouver sur le web : imaginons un site web qui offre des statistiques sur par exemple des courses de chevaux. Il récupère les résultats bruts sous forme de fichiers CSV et il a un petit programme "stats" qui appliqué à un fichier d'une course crée un fichier de statistiques. Par paresse le formulaire du site web qui permet de choisir la course dont on veut consulter les statistiques n'offre pas une liste déroulante de choix mais juste un champ de texte dans lequel on entre le nom de la course.
Au final, dans son script CGI, on trouve l'instruction suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

system("stats $course_name.csv >$course_name.st");

... (et là normalement tu pousses des cris d'horreur, sinon c'est que soit tu ne t'y connais pas bien du tout en Perl/PHP/Bash, soit tu dois redoubler de prudence parce que tu es susceptible aux erreurs classiques)
Parce que si l'utilisateur malveillant s'avise par exemple d'écrire plutôt :
"chambond; rm -rf . #" dans son champ de texte, le webmaster n'aura plus que ses yeux pour pleurer...

Bon cet exemple particulier est impossible en Perl avec le mode tainté (ou du moins très difficile, il faut y mettre une mauvaise volonté particulière) et de toute façon on espère bien que ton serveur est sur une machine Unix/Linux bien configurée de sorte que la commande en question n'ai pas d'effets, néanmoins, il s'agit d'un exemple typique des erreurs qu'on peut rencontrer tous les jours sur le net (parfois de façon plus subtile, mais pas toujours).

--
Jedaï

[Mat_F]

Merci Jedai pour ta réponse, et d'avoir pris la peine de fournir un exemple concret. Mais il me reste encore visiblement pas mal de trucs à comprendre...

Tu devrais commencer par lire attentivement la documentation du module CGI (qui est la bonne façon de faire du CGI en Perl aujourd'hui, tiens toi à bonne distance de tout script qui utiliserait encore cgi-lib ou autre horreur des temps antiques...) et de DBI (particulièrement la partie sur les placeholders, qui t'éviteront toute injection SQL) ainsi que la section de la doc sur le mode tainted.

Pourrais-tu STP m'indiquer où trouver cette "doc du module CGI" ?

... (et là normalement tu pousses des cris d'horreur, sinon c'est que soit tu ne t'y connais pas bien du tout en Perl/PHP/Bash, soit tu dois redoubler de prudence parce que tu es susceptible aux erreurs classiques)

J'ai comme l'impression que c'est la 2ème option qui s'applique à mon cas...

Parce que si l'utilisateur malveillant s'avise par exemple d'écrire plutôt : "chambond; rm -rf . #" dans son champ de texte, le webmaster n'aura plus que ses yeux pour pleurer...

Je n'ai rien compris, mais je vais creuser un peu le sujet...

[Jasmine80]

Pourrais-tu STP m'indiquer où trouver cette "doc du module CGI" ?

En perl, le site de référence des modules est le CPAN, tu peux toujours commencer par regarder sur ce site-là
http://search.cpan.org/~lds/CGI.pm-3.38/CGI.pm

Citation:
Envoyé par Jedai Voir le message
Parce que si l'utilisateur malveillant s'avise par exemple d'écrire plutôt : "chambond; rm -rf . #" dans son champ de texte, le webmaster n'aura plus que ses yeux pour pleurer...

Je n'ai rien compris, mais je vais creuser un peu le sujet...

Apparemment, tu envoies directement une commande au système
system("stats $course_name.csv >$course_name.st");

Mais si tu es mal intentionné et que tu envoies
chambond; rm -rf . #

... le rm ressemble méchamment à une commande remove ^^ et -rf à un groupe de fichiers

Donc, la conclusion serait de ne pas exécuter bêtement la commande que l'utilisateur entre mais de l'analyser avant de la passer au système.

[Jedai]

En perl, le site de référence des modules est le CPAN, tu peux toujours commencer par regarder sur ce site-là
http://search.cpan.org/~lds/CGI.pm-3.38/CGI.pm

Le CPAN est une ressource formidable, mais dans le cas particulier de CGI, il est distribué en standard avec Perl, donc tu trouves sa documentation sur ton système normalement (commande "perldoc CGI" ou "man CGI" selon ton système) ou sur le site de référence. Par ailleurs n'oublie pas que nous avons une FAQ sur notre site, où tu peux trouver entre autre ces références ainsi que bien d'autres éléments (regarde par exemple en haut de ce forum).

Apparemment, tu envoies directement une commande au système
system("stats $course_name.csv >$course_name.st");

Mais si tu es mal intentionné et que tu envoies
chambond; rm -rf . #

... le rm ressemble méchamment à une commande remove ^^ et -rf à un groupe de fichiers

Donc, la conclusion serait de ne pas exécuter bêtement la commande que l'utilisateur entre mais de l'analyser avant de la passer au système.

Tout à fait, "rm" est la commande "remove" (suppression de fichiers/dossiers), -r lui dit d'être récursif (supprimer les sous-dossiers et leur contenu) et -f lui dit de ne pas poser de question. "rm -rf ." correspond donc à la suppression du répertoire courant (probablement cgi-bin). Il y a bien pire comme attaque mais celle là aurait déjà fait tomber ton site (sur un serveur Windows à l'ancienne). L'erreur ici tient à ce que le webmaster a assumé que $coursename ne contiendrait jamais autre chose qu'un nom de course. Or le contenu de cette variable lui vient de l'utilisateur et n'a jamais été vérifié, il peut donc parfaitement contenir une commande malicieuse dans un langage quelconque et le passer directement dans une commande system() est de l'inconscience pure.
Heureusement, en suivant les quelques conseils que je t'ai donné tu peux déjà limiter sérieusement les risques : en particulier le mode tainté de Perl t'interdira catégoriquement d'utiliser du contenu provenant de l'utilisateur dans des fonctions dangereuses (open, system, les backticks....) si tu ne l'as pas vérifié soigneusement avant.

--
Jedaï

[Mat_F]

Bon j'ai passé pas mal de temps à lire tout ça...

Si j'ai bien compris, le "module CGI" sert à produire du code HTML, mais ça n'a pas l'air indispensable - pour ma part je génère tout le code moi-même.

Sinon à propos du mode "tainted" (dont la doc n'est selon moi vraiment pas très claire) ça m'a tout l'air d'une excellente chose, le seul hic c'est que je ne sais pas comment l'activer sous Windows. J'ai lu de l'info là-dessus mais je ne vois pas trop ce qu'il faut faire concrètement. Faut-il configurer IIS ? Si oui, comment ?

[CKLN00]

bon ne sachant pas si finalement tu as eut le temps de lire le message que je t'adressait hiere je le remet (version plus courte :p).
Je te conseille très vivement d'aller lire ça et ça, et si tu n'est pas décourager par l'anglais la documentation officiel du pour le CGI