La gestion de la sécurité

Accès en clair La recherche suivante « mysql filetype:inc » sur Google vous montre à quel point il peut être simple de découvrir les identifiants et les mots de passe d’accès à une multitude de bases de données. Il convient donc de vérifier auprès de votre administrateur système si l’extension choisie pour les includes peut convenir. Ajout d’extensions dans Apache La directive AddHandler permet de définir les extensions des scripts PHP : AddHandler application/x−httpd−php .php .php3 .inc. Il conviendra également de vérifier qu’aucun répertoire sensible ne soit listé. Apache permet en effet de lister l’ensemble des fichiers contenus dans un répertoire si ce répertoire contient l’option Indexes : Options Indexes Fichier index La liste des fichiers n’est proposée que si le répertoire ne contient pas de fichier index (par exemple index.html, index.htm, index.php, etc.). La liste de ces fichiers peut être modifiée dans le fichier httpd.conf avec la directive DirectoryIndex. Figure 16.18 : Exemple de liste de fichiers .La gestion de la sécurité L’ajout des directives suivantes en bas du fichier de configuration d’Apache (httpd.conf) permet d’interdire l’accès au répertoire testindexes : Options -Indexes 

La sécurité HTTPS

HTTPS correspond au protocole HTTP complété d’une couche SSL (Secure Socket Layer) de cryptage des données. Cette protection est particulièrement utile pour lutter contre les attaques de sniffing. Le sniffing peut être rapproché d’une écoute des données transitant entre votre navigateur et le serveur web. Sans la couche SSL, ces mêmes données circulent en clair sur le réseau. Lorsqu’il s’agit d’une page d’informations, le risque est inexistant. Lorsqu’il s’agit en revanche d’une authentification, votre identifiant et votre mot de passe apparaissent en clair sur l’écran du pirate. En configurant l’extension SSL d’Apache (mod_ssl), vous vous assurez de l’anonymat de vos échanges. Cette technique se révèle superflue dans 90 % des cas. Le point central du sniffing consiste à pouvoir se « brancher » sur la liaison Internet de la cible. Or, ce n’est possible que si l’attaquant se trouve dans un réseau local, non loin de la machine cible.

 Les outils d’analyse

Compte tenu de l’importance que prennent les applications web dans l’économie moderne, certains éditeurs ont sauté sur l’occasion pour proposer des outils permettant de les auditer. Figure 16.19 : Le répertoire ne peut plus être « listé » Les outils d’analyse  Le logiciel Acunetix Web Vulnerability Scanner (www.acunetix.com/wvs) par exemple, permet à partir d’une simple adresse web, de tester les attaques sur des failles du langage, les injections SQL, les attaques de type XSS (Cross Site Scripting), les attaques concernant les passages de paramètres, les formulaires d’authentification (en veillant à ce que les identifiants et les mots de passe ne soient pas trop simples à trouver), ainsi qu’une dizaine d’autres attaques classiques. 16.5. Check-list La sécurité est un domaine complexe. Plusieurs règles doivent systématiquement rester à votre esprit durant la phase de développement : j Les paramètres reçus dans un script peuvent être forcés par un utilisateur malicieux qui composerait sa propre Query String ou qui modifierait ses cookies. Les paramètres reçus dans un script doivent donc toujours être vérifiés avant d’être exploités. j La vérification doit être encore plus poussée lorsqu’il s’agit de composer une requête SQL à partir de paramètres. j Il est important de logger les événements étranges et incohérents qui ont lieu au sein de votre applicatif. Cela sera votre première source d’information en cas d’attaque. j Les rapports d’erreur doivent être le plus complets possible durant la phase de développement. Ils vous permettront notamment de détecter les variables non initialisées.