Un serveur HTTP est en écoute sur le port 80. Le protocole HTTP est sûrement le plus utilisé sur le web pour les pages html. Ce protocole ne comporte pas de failles intrinsèques majeures. En revanche, les applications assurant son traitement sont souvent bourrées de failles. Cela vient du fait que le web devient de plus en plus demandeur en terme de convivialité et cela génère une complexité plus grande des applications, d'où un risque de failles plus important.
Nous allons décrire ces failles une à une.
Parfois, les bannières des serveurs web sont trop explicites. Exemple sur un serveur Apache :
[root@nowhere /root]# telnet 127.0.0.1 80 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. HEAD / HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 04 Jan 2004 15:07:06 GMT Server: Apache/1.3.29 (Debian GNU/Linux) Last-Modified: Sat, 24 Nov 2001 16:48:12 GMT ETag: "17082-100e-3bffcf4c" Accept-Ranges: bytes Content-Length: 4110 Connection: close Content-Type: text/html; charset=iso-8859-1 Connection closed by foreign host.
Lors de l'envoi de la commande HEAD / HTTP/1.0, trop
d'informations sont données.
Les pages d'erreurs (404 : page non trouvée) peuvent aussi contenir des informations sur le système.
La complexité des serveurs ou des navigateurs (clients) web pose de gros problèmes de sécurité. Ces applications sont vulnérables à de nombreux bugs. Chaque application a son type de faille. Netscape par exemple devient vulnérable lors du traitement de certaines chaînes de caractères. Cela peut permettre de remonter toute l'arborescence des fichiers du serveur. Les serveurs IIS peuvent renvoyer un shell système pour un envoi de commandes particulières.
Les langages comme Javascript, Perl, PHP, ASP pour la réalisation de scripts peuvent se rélèver dangereux. L'origine d'une faille dans une application web peut apparaître à cause de deux problèmes. Le premier est la fiabilité de la conception du script, le second est la fiabilité des fonctions utilisées. Si un script est mal conçu, il peut être la source de nombreuses failles. De même, si sa conception est bonne mais qu'il utilise des fonctions boguées, il peut se révéler encore plus dangeureux.
Vérifiez que votre serveur web n'est pas trop bavard. Si c'est le cas, modifiez sa configuration pour qu'il se taise. Pour cela, consultez la documentation pour modifier le contenu des messages d'erreur ou de bienvenue.
Un serveur web ne devrait jamais être exécuté avec les droits administrateurs.
Mettez à jour les navigateurs et les serveurs pour prévoir d'éventuelles failles.
Lors du développement de scripts, prenez garde lors de la conception à la gestion des droits des utilisateurs pour son exécution. Informez-vous aussi sur les fonctions connues pour être «sensibles».
Les NIDS peuvent être une bonne parade contre les attaques reposant sur des failles logicielles. Ils permettent de détecter l'exécution de telles attaques (Voir Section 4.3, « Les systèmes de détection d'intrusion (HIDS/NIDS) »).
L'utilisation de SHTTP (Secure HTTP) est aussi une bonne parade contre les attaques HTTP.
Une bonne définition de SHTTP est donné par E.Rescorla et A. Schiffman :
"Le protocole SHTTP est une extension de HTTP qui fournit des services de sécurité, applicables indépendamment, qui permettent de garantir la confidentilité, l'authenticité/intégrité, et le non refus d'origine."
SSL ("Secure Socket Layer" pour Netscape) permet de protéger les transactions web, il peut être judicieux de l'utiliser.