Web14 : Problèmes de sécurité dans le protocole HTTP

Cet article présente certains problèmes de sécurité dans le protocole HTTP , soulevés dans deux documents RFC 7230 et RFC 7231. Les exemples de l'article sur des erreurs spécifiques sont référencés dans OWASP.

1. Risques liés à des facteurs intermédiaires

HTTP permet l'utilisation d'intermédiaires pour répondre aux demandes via une série de connexions. Il existe trois éléments intermédiaires communs : proxy, passerelle et tunnel.

Une demande ou une réponse devra passer par les points A, B et C. Ils peuvent accéder aux informations sensibles transmises, telles que les informations personnelles des utilisateurs ou des organisations. Le manque d’attention accordé par les intermédiaires à la sécurité et à la confidentialité peut conduire à un large éventail d’attaques potentielles.

Les développeurs de systèmes et les développeurs doivent prendre en compte les facteurs de confidentialité et de sécurité lors du processus de conception, de codage et de déploiement du système.

Les utilisateurs doivent être conscients des dangers liés à l’utilisation de proxys ou de passerelles non fiables.

2. Fractionnement des réponses

Le fractionnement des réponses (alias injection CRLF) est une technique d’exploitation Web populaire. L'attaquant envoie des données codées, dans certains paramètres de la requête, qui sont ensuite décodées et répétées dans un certain champ de l'en-tête de réponse.

Si ces données sont un symbole représentant la fin de la réponse et qu'une réponse ultérieure est initiée, la réponse originale sera divisée en deux et le contenu de la deuxième réponse sera contrôlé par l'attaquant. L'attaquant peut alors effectuer une autre requête au sein de la même connexion persistante et faire croire au destinataire (y compris les intermédiaires) que cette seconde réponse est une réponse à la seconde requête.

3. Demander de la contrebande

La contrebande de requêtes est une technique qui exploite les différences dans le traitement des requêtes par différents types de serveurs pour masquer des requêtes apparemment inoffensives ajoutées à la requête d'origine.

Considérons l'exemple suivant :

Supposons qu'une requête POST contienne deux champs « Content-length » dans l'en-tête avec deux valeurs différentes. Certains serveurs refuseront cette demande (IIS et Apache), mais d'autres non. Par exemple, SunONE W/S 6.1 utilise le champ Content-length en premier, tandis que sunONE Proxy 3.6 utilise le champ Content-length en second.

En supposant que SITE soit le DNS d'un SunONE W/S, situé derrière un proxy SunONE, il existe un fichier poison.html situé sur le SunONE W/S. Voici comment exploiter la fraude de requêtes HTTP en fonction des incohérences de traitement entre deux serveurs :

[Notez que chaque ligne se termine par un CRLF (« »), sauf la ligne 10]

Considérons ce qui se passe lorsqu'une requête est envoyée à W/S via le serveur proxy. Tout d'abord, le proxy analysera la requête des lignes 1 à 7 (bleues) et rencontrera deux champs Content-Length. Comme mentionné ci-dessus, il ignorera le premier champ et comprendra que le corps de la requête fait 44 octets. Par conséquent, il traite les données des lignes 8 à 10 comme le corps de la première requête (des lignes 8 à 10, les données font exactement 44 octets). Le proxy analysera alors les lignes 11 à 14 (en rouge) comme deuxième requête du client.

Voyons maintenant comment W/S interprète les données ci-dessus, telles qu'elles sont transmises depuis le proxy. Contrairement aux proxys, W/S utilisera le premier champ Content-Length et l'interprétera comme suit : la première requête n'a pas de corps et la deuxième requête commence à partir de la ligne 8 (notez que W/S analysera à partir de la ligne 11 comme valeur du champ Bla).

Voyons ensuite comment la réponse est renvoyée au client. La requête que W/S comprend est « POST /foobar.html » (à partir de la ligne 1) et « GET /poison.html » (à partir de la ligne 8), il enverra donc au client 2 réponses avec le contenu de la page foobar. html et poison.html. Le proxy comprend que ces 2 réponses correspondent à 2 requêtes : "POST /foobar.html" (de la ligne 1) et "GET /page_to_poison.html" (ligne 11). Le proxy mettra en cache le contenu de la page poison.html correspondant à l’URL « page_to_poison.html » (empoisonnement du cache). A partir de là, lorsque le client demandera "page_to_poison.html", il recevra le contenu de la page poison.html.

4. Attaque basée sur le chemin du fichier

Les serveurs Web utilisent fréquemment leur système de fichiers local pour gérer le mappage des noms de fichiers dans les URI avec les ressources réelles du serveur. La plupart des systèmes de fichiers ne sont pas conçus pour protéger contre les chemins de fichiers malveillants. Par conséquent, le serveur doit éviter d’accéder aux fichiers système importants.

Par exemple, UNIX, Microsoft Windows et plusieurs autres systèmes d'exploitation utilisent « .. » comme élément de chemin pour représenter un répertoire situé un niveau au-dessus du fichier/répertoire actuel. Sans contrôle d'entrée et autorisation appropriés, les fichiers/dossiers sensibles du système sont accessibles en saisissant des chemins pointant vers ces fichiers/dossiers.

5. Types d'attaques : injection de commandes, injection de code, injection de requêtes

[Les serveurs Web utilisent souvent les paramètres de l'URI comme entrée pour exécuter des commandes système et des requêtes de base de données. Cependant, les données reçues dans la demande ne sont pas toujours fiables. Un attaquant peut créer et modifier des composants dans la requête (comme des méthodes, des champs dans l'entête, le corps...), pour exécuter des commandes système, interroger la base de données...

Par exemple, l'injection SQL est une attaque courante dans laquelle le serveur Web reçoit des paramètres dans l'URI qui font partie de la requête SQL. Ainsi, un attaquant peut tromper le serveur web pour qu'il exécute des requêtes SQL illégales, afin de voler ou de saboter la base de données.
En général, les données soumises par les utilisateurs ne doivent pas être utilisées directement pour effectuer des opérations sur le serveur. Ces données doivent passer par des filtres qui définissent ce qui est valide et ce qui ne l'est pas, éliminant ainsi les données indésirables.

6. Révélation d'informations personnelles

Les clients contiennent souvent de nombreuses informations personnelles, notamment des informations fournies par l'utilisateur pour interagir avec le serveur (telles que le nom d'utilisateur, le mot de passe, l'emplacement, l'adresse e-mail, etc.) et des informations sur les activités de navigation Web de l'utilisateur (historique, favoris, etc.). Lors de la mise en œuvre, il convient de veiller à éviter les points susceptibles de révéler ces informations privées.

7. Révéler des informations sensibles dans l'URI

Les URI, de par leur conception, sont destinés à être partagés avec tous les utilisateurs et leur sécurité n'est pas garantie. Les URI sont souvent affichés dans le code source du site Web et stockés dans des signets sans mécanismes de protection. Par conséquent, il sera dangereux si l’URI contient des informations sensibles, des informations personnelles, etc.

Évitez d'utiliser la méthode GET pour envoyer des informations personnelles au serveur, car elles seront affichées dans l'URI. Utilisez plutôt la méthode POST.

8. Révéler les informations sur les logiciels utilisés

Les champs User-Agent, Via, Server dans l'en-tête fournissent généralement des informations sur le logiciel utilisé par l'expéditeur. En théorie, cela permet aux attaquants d’exploiter plus facilement les vulnérabilités connues de ces logiciels.