CGI:Sécurité
Un article de WikiTuto.
Ce point, fondamental, fait l'objet d'une F.A.Q. sur le site du W3C. Cette partie du cours en est une traduction partielle. Elle s'applique à toutes sortes de scripts, qu'ils soient écrits en C, en Perl ou tout autre langage.
Quel est le problème, au juste ?
Le principal problème avec les scripts CGI est que chacun d'eux peut présenter une faille de sécurité différente. Les scripts devraient être écrits avec la même attention et le même soin que les serveurs eux-mêmes car, fondamentalement, ce sont des serveurs en miniature. Malheureusement, pour la plupart des auteurs de CGI, c'est là leur premier contact avec la programmation d'application en réseau.
Les scripts peuvent présenter deux types de failles de sécurité :
- ils peuvent, volontairement ou non, laisser filtrer des informations sur le serveur ;
- les scripts qui demandent à l'utilisateur des données, que ce soit le remplissage de champs de formulaire, ou un simple script de recherche sur un site, sont vulnérables à des attaques où les utilisateurs peuvent les amener à exécuter des commandes.
Tout est virtuellement accessible : listings de mots de passe, plan du sous-réseau, même l'ouverture d'une session telnet ou autre sur un port élevé, consultation de fichiers, etc.
Où installer un script ?
Bien qu'il n'y ait rien de spécialement dangereux à disséminer les scripts dans plusieurs répertoires, il est préférable de les rassembler dans le répertoire cgi-bin. Il sont en effet plus facilement maintenables. Cela est plus particulièrement recommandé dans le cadre d'un site pris en charge par plusieurs auteurs. Il est alors recommandé de restreindre les droits d'installation des scripts à l'administrateur, dans un répertoire dédié.
Il y a aussi le risque qu'un pirate arrive à créer in script quelque part dans l'arborescence, et l'exécute à distance en tapant directement son URL.
Est-ce qu'un langage compilé comme le C est plus sécurisé qu'un langage interprété comme Perl ?
La réponse est simple : oui.
La première raison en est la facilité d'accès d'un utilisateur distant au code source. Plus les informations qu'il recueille sur le fonctionnement du script sont nombreuses, plus un pirate est susceptible d'en trouver les défauts et bogues. Avec un script écrit dans un langage compilé comme le C, seul le binaire peut être déposé sur le serveur, laissant le code source à l'abri de tout regard indiscret. En revanche, avec un script écrit dans un langage interprété, le code source est toujours potentiellement accessible, même sur un serveur configuré proprement.
Considérons par exemple l'exemple suivant. Pour des raisons de simplicité, vous avez décidé de donner à tous vos scripts Perl l'extension .cgi. Plus tard, vous décidez d'apporter une modification mineure, et ouvrez le code avec un éditeur comme emacs. Il se trouve que cet éditeur laisse derrière lui une copie de sauvegarde de la version non modifiée, portant l'extension .cgi~. Un utilisateur distant n'a pas accès au code source du script lui-même ; en revanche, il peut avoir accès à la version antérieure, en tapant en aveugle le nom du script, et en lui ajoutant ~. Par exemple, supposons que l'URL du script soit http://www.monsite.com/cgi-bin/recherche.cgi. Cette adresse apparaît en clair dans la barre d'adresse du navigateur. Il est alors possible d'avoir accès au code source de la version précédente en tapant dans la barre http://www.monsite.com/cgi-bin/recherche.cgi~.
Une autre raison réside dans la taille et la complexité. Les gros programmes, comme l'interpréteur Perl, sont plus susceptibles de comporter des bogues que les plus petits. Certains de ces bogues peuvent ouvrir des failles de sécurité. Et vous n'avez aucun contrôle, la plupart du temps, sur ces failles...
De plus, une particularité des langages de script interprété est qu'ils rendent l'accès aux commandes systèmes aisé. Il est logique que la possibilité de pouvoir lancer des commandes systèmes, et récupérer leur sortie, est une faille de sécurité majeure. En C, la tâche est plus difficile si elle n'a pas été prévue à l'origine dans le programme.
Pour conclure, les programmes C peuvent contenir des bogues exploitables. Utiliser un langage interprété permet à d'autres auteurs d'éventuellement corriger plus facilement un bogue, car ils sont en général plus facilement compréhensibles. De plus, Perl contient de nombreuses fonctionnalités permettant de gérer des failles possibles.
Comment savoir si un script que j'ai trouvé sur le Web est sûr ou non ?
C'est impossible. A priori, un script doit être considéré comme non sûr. Une mesure évidente consiste en ne jamais télécharger un script donc on ne dispose que du binaire. Ceci étant posé, il faut toujours inspecter soigneusement le code, si on dispose des compétences nécessaires pour l'analyser, sinon le faire examiner par quelqu'un d'autre. Voici quelques petites choses à vérifier :
- Quelle est sa longueur ? Plus il est long, plus il est susceptible de poser des problèmes ;
- Ecrit-il ou lit-il des fichiers sur le serveur ? Les programmes qui lisent des fichiers peuvent par inadvertance violer des restrictions d'accès que vous auriez mises en place, ou passer des informations critiques à des pirates. Ceux qui écrivent des fichiers peuvent modifier ou endommager des documents, voire dans le pire cas introduire un cheval de Troie dans le système ;
- Interagit-il avec d'autres programmes sur le système ? Par exemple, beaucoup de scripts envoient une reponse par courrier électronique après le remplissage d'un formulaire par un utilisateur, en passant par le programme sendmail du serveur. Cette interaction est-elle correctement écrite et sûre ?
- Permet-il de modifier des droits d'accès de certains utilisateurs ? Cette possibilité, hautement risquée, doit être réservée aux cas où elle est absolument indispensable ;
- Est-ce qu'une validation de la saisie des données dans le formulaire est prévue par l'auteur ? Par exemple, vérifier le contenu des chaînes de caractères, imposer un format particulier, une longueur maximale, etc ;
- Est-ce que l'auteur a utilisé des noms de chemins d'accès explicites ? Cela peut donner des informations critiques à un éventuel pirate.
Je développe mes propres scripts. Que dois-je éviter de faire ?
1-Eviter de donner trop d'informations sur votre site et le serveur.
Bien qu'ils permettent parfois des effets intéressants, de tels scripts présentent des failles de sécurité qui doivent être évitées.
2-Si vous utilisez un langage compilé comme le C, il faut éviter de faire des hypothèses sur la longueur des chaînes de données fournies par l'utilisateur. Voici un exemple simple :
#include <stdlib.h>
#include <stdio.h>
static char query_string[1024];
char * read_POST()
{
int query_size;
query_size=atoi(getenv("CONTENT_LENGTH"));
fread(query_string, query_size, 1, stdin);
return query_string;
}
Le problème dans l'exemple ci-dessus est que l'auteur a fait l'hypothèse a priori que les données fournies par l'utilisateur ne dépassent jamais la taille définie du tampon d'entrée, 1024 octets dans cet exemple. Un pirate peut casser ce type de programme en fournissant une entrée dépassant largement la taille maximale prévue par l'auteur. Le tampon est débordé, et peut faire "planter" le programme. Parfois, le plantage peut être exploité par le pirate et lui permettre de lancer des commandes à distance.
Cette version "simple" de la procédure permet de régler ce problème :
char * read_POST()
{
int query_size=atoi(getenv("CONTENT_LENGTH"));
char * query_string=(char*) malloc(query_size);
if (query_string != NULL)
fread (query_string, query_size, 1, stdin);
return query_string;
}
Bien sûr, les mêmes précautions doivent être prises tout au long du code.
3-Ne jamais, jamais, jamais envoyer directement une chaîne entrée par l'utilisateur vers un shell. En C, cela concerne les appels aux fonctions popen et system.
