L'équipe Vigil@nce veille les vulnérabilités publiques qui affectent votre parc informatique, puis propose des correctifs sécurité, une base et des outils pour y remédier.

Vulnérabilités informatiques de HTTP (protocole)

bulletin de vulnérabilité informatique 20428

HTTP : Man-in-the-Middle via Proxy CONNECT

Synthèse de la vulnérabilité

Un attaquant peut se positionner en Man-in-the-Middle lorsqu'un proxy HTTP est configuré, afin d'obtenir les mots de passe des utilisateurs de ce proxy.
Produits concernés : HTTP (protocole), SSL (protocole).
Gravité : 1/4.
Conséquences : lecture de données, création/modification de données.
Provenance : serveur intranet.
Date création : 18/08/2016.
Références : FalseCONNECT, VIGILANCE-VUL-20428, VU#905344.

Description de la vulnérabilité

Lorsqu'un proxy HTTP est configuré, le navigateur web utilise la méthode HTTP CONNECT pour demander au proxy de créer une session TLS sécurisée.

Cependant, la requête HTTP CONNECT et sa réponse transitent dans une session HTTP en clair. Un attaquant peut se positionner en Man-in-the-Middle, et usurper une réponse 407 Proxy Authentication vers le client. La victime voit alors une fenêtre d'authentification apparaître, et peut re-saisir son mot de passe, qui est envoyé au serveur de l'attaquant.

On peut noter que cette vulnérabilité affecte tous les types de session demandés au proxy, mais comme la victime demande une url https/TLS, elle s'attend à ce que la session soit chiffrée. C'est donc un problème de perception plutôt qu'un nouvelle vulnérabilité réelle.

Un attaquant peut donc se positionner en Man-in-the-Middle lorsqu'un proxy HTTP est configuré, afin d'obtenir les mots de passe des utilisateurs de ce proxy.
Bulletin Vigil@nce complet... (Essai gratuit)

vulnérabilité informatique 17985

HTTPS : injection de Cookie

Synthèse de la vulnérabilité

Un attaquant peut injecter un Cookie dans une session HTTPS (HTTP+TLS), afin d'altérer le comportement du service web, si ce dernier n'est pas conçu pour recevoir des cookies non prévus.
Produits concernés : Chrome, Edge, IE, Firefox, SeaMonkey, Opera, HTTP (protocole).
Gravité : 1/4.
Conséquences : création/modification de données.
Provenance : serveur internet.
Date création : 25/09/2015.
Références : VIGILANCE-VUL-17985, VU#804060.

Description de la vulnérabilité

Les cookies (RFC 6265) sont des entêtes HTTP additionnels définis par un serveur web, puis retournés par le client lorsqu'il accède de nouveau au serveur web.

Cependant, la RFC 6265 ne demande pas au navigateur web de renvoyer le cookie à travers le même canal que celui à travers lequel il est arrivé. Ainsi :
 - le site http://example.com/ (ou un attaquant usurpant ce serveur) peut définir un cookie, qui sera renvoyé vers http://autre.example.com/ et https://autre.example.com/
 - le site http://www.example.com/ (ou un attaquant usurpant ce serveur) peut définir un cookie avec le drapeau "secure", qui sera renvoyé vers https://www.example.com/

Un attaquant peut donc injecter un Cookie dans une session HTTPS (HTTP+TLS), afin d'altérer le comportement du service web, si ce dernier n'est pas conçu pour recevoir des cookies non prévus.
Bulletin Vigil@nce complet... (Essai gratuit)

alerte de vulnérabilité informatique 8726

HTTP : gestion incohérente des paramètres

Synthèse de la vulnérabilité

Le protocole HTTP ne définit pas le comportement des serveurs web face à une requête contenant plusieurs fois la même variable, ce qui peut provoquer des vulnérabilités.
Produits concernés : HTTP (protocole), Unix (plateforme) ~ non exhaustif.
Gravité : 1/4.
Conséquences : lecture de données, création/modification de données, transit de données.
Provenance : client internet.
Date création : 20/05/2009.
Date révision : 12/06/2009.
Références : BID-35323, VIGILANCE-VUL-8726.

Description de la vulnérabilité

La RFC 2616 définit le protocole HTTP. La RFC 3986 définit la syntaxe des uris. Par exemple :
  http://serveur/page?var1=val1&var2=val2
Ces RFC ne définissent pas comment gérer les urls contenant plusieurs fois le même nom de variable. Par exemple :
  http://serveur/page?var=val1&var=val2

Les développeurs de services HTTP ont donc fait des choix différents :
 - ASP.NET : la valeur utilisée est la concaténation des paramètres ("val1,val2")
 - PHP : la valeur utilisée est le dernier paramètre ("val2")
 - JSP : la valeur utilisée est le premier paramètre ("val1")
 - Zope : la valeur utilisée est un tableau (['val1', 'val2'])

De même, si un paramètre est défini dans le Query String et dans un Cookie, les comportements divergent. Par exemple :
  POST /page?var=val1
  Cookie: var=val2
  \n
  var=val3

Un attaquant peut donc employer ces incohérences afin par exemple de contourner les IDS ou les modules de filtrage web.

Ces vulnérabilités ont été regroupées sous le terme HPP (HTTP Parameter Pollution).
Bulletin Vigil@nce complet... (Essai gratuit)

annonce de vulnérabilité informatique CVE-2008-3663

HTTP : capture de cookie

Synthèse de la vulnérabilité

Un attaquant peut obtenir un cookie ne possédant pas l'attribut secure.
Produits concernés : Fedora, openSUSE, HTTP (protocole), SSL (protocole), RHEL, SLES, Unix (plateforme) ~ non exhaustif.
Gravité : 1/4.
Conséquences : lecture de données.
Provenance : LAN.
Date création : 23/09/2008.
Références : BID-31321, CERTA-2008-AVI-529, CVE-2008-3663, FEDORA-2008-8559, FEDORA-2008-9071, MDVSA-2009:053, RHSA-2009:0010-01, RHSA-2009:0057-01, SUSE-SR:2008:028, VIGILANCE-VUL-8127.

Description de la vulnérabilité

Le protocole HTTP définit des cookies :
 - le serveur retourne un cookie au client
 - le client envoie ce cookie à chaque nouvelle connexion sur le serveur

Par exemple :
 - le client se connecte sur https://serveur/page1 et obtient un cookie
 - le client se connecte sur https://serveur/page2 et envoie ce cookie
 - le client se connecte sur http://serveur/page3 et envoie ce cookie
Le cookie a été obtenu dans la session sécurisée ("https://" = HTTP sur SSL) de la page1, et est envoyé pour la page 3 en "http://", c'est-à-dire qu'il circule en clair sur le réseau. Pour empêcher cela, l'attribut "secure" d'un cookie indique qu'il peut uniquement être employé au sein d'une session SSL.

Certains services n'utilisent pas l'attribut "secure", car toute connexion sur le port 80/http redirige vers le port 433/https, et les développeurs pensent donc que le port 80 ne sera jamais utilisé. Cependant, les victimes se connectent sur le port 80 (ou sont redirigés par un attaquant via une redirection permanente 301). Le cookie circule donc en clair (port 80) avant de passer dans la session SSL (port 443).

Cette vulnérabilité affecte notamment SquirrelMail.
Bulletin Vigil@nce complet... (Essai gratuit)

annonce de vulnérabilité informatique CVE-2005-0175 CVE-2005-2090

HTTP : injection de réponses

Synthèse de la vulnérabilité

Un attaquant peut injecter des données dans une requête HTTP dans le but de produire deux ou plusieurs réponses HTTP.
Produits concernés : Debian, Fedora, HP-UX, WebSphere AS Traditional, Mandriva Linux, IIS, ISA, NetCache, openSUSE, Oracle iPlanet Web Server, WebLogic, HTTP (protocole), RHEL, RedHat Linux, Squid, TurboLinux.
Gravité : 1/4.
Conséquences : transit de données.
Provenance : document.
Nombre de vulnérabilités dans ce bulletin : 3.
Date création : 05/03/2004.
Dates révisions : 09/03/2004, 25/01/2005.
Références : 20050203-01-U, BID-9804, c01178795, CERTA-2008-AVI-008, CERTA-2009-AVI-032, CVE-2005-0175, CVE-2005-1389-REJECT, CVE-2005-2090, DSA-667, DSA-667-1, FEDORA-2014-13764, FEDORA-2014-13777, FLSA-2006:152809, HPSBUX02262, MDKSA-2005:034, RHSA-2005:060, RHSA-2005:061, RHSA-2008:0261-01, SGI 20050203, SQUID-2005_5, SSRT071447, SUSE-SA:2005:006, TLSA-2005-24, V6-HTTPRESPONSESPLITTING, VIGILANCE-VUL-4047, VU#625878.

Description de la vulnérabilité

Une réponse HTTP comporte des entêtes séparés par des sauts de ligne. Par exemple :
  HTTP/1.1 200 OK
  entete1: valeur1
  entete2: valeur2

De nombreuses implémentation de HTTP ou de langages générant du code HTTP ne s'assurent pas que les valeurs ne contiennent pas de saut de ligne. Lorsque ces valeurs peuvent être indirectement affectées par un attaquant, il peut par exemple utiliser pour valeur1 :
  aa saut_de_ligne fausse_fin_de_la_réponse_HTTP autre_réponse_HTTP
Le serveur web génère alors :
  HTTP/1.1 200 OK
  entete1: aa
  fausse_fin_de_la_réponse_HTTP
  autre_réponse_HTTP
  entete2: valeur2
On obtient ainsi 2 réponses HTTP à la suite

Si l'attaquant provoque le téléchargement d'un deuxième document, le contenu de "autre_réponse_HTTP" s'affichera dans le navigateur au lieu du deuxième document désiré.

Cette vulnérabilité, dont la mise en oeuvre est parfois complexe, permet donc à un attaquant :
 - de mener des attaques de type Cross Site Scripting
 - de changer l'apparence d'un document (et éventuellement d'empoisonner un cache)
Bulletin Vigil@nce complet... (Essai gratuit)

bulletin de vulnérabilité informatique CVE-2004-2320 CVE-2005-3398

Utilisation de la méthode TRACE en complément d'une attaque Cross Site Scripting

Synthèse de la vulnérabilité

La méthode HTTP TRACE permet d'obtenir des compléments d'informations suite à une attaque de type Cross Site Scripting.
Produits concernés : Apache httpd, HPE BSM, HP-UX, Domino, IIS, IE, Oracle iPlanet Web Server, Solaris, Trusted Solaris, WebLogic, HTTP (protocole), Sun AS.
Gravité : 1/4.
Conséquences : accès/droits client.
Provenance : document.
Nombre de vulnérabilités dans ce bulletin : 2.
Date création : 23/01/2003.
Dates révisions : 24/01/2003, 27/01/2003, 13/02/2003, 05/05/2003, 08/09/2003, 27/01/2004, 04/11/2004.
Références : 101176, 102016, 1201202, 200171, 200942, 5063481, 5090761, BEA04-48.00, BEA-048, BID-11604, BID-15222, BID-9506, BID-9561, c00612828, CVE-2004-2320, CVE-2005-3398, HP279, HPSBUX02101, KM03235847, SSRT051128, Sun Alert 50603, Sun Alert 57670, Sun Alert ID 50603, Sun Alert ID 57670, Sun BugID 4808654, Sun BugID 5063481, V6-XSSTRACING, VIGILANCE-VUL-3278, VU#867593.

Description de la vulnérabilité

Le protocole HTTP définit plusieurs méthodes :
 - HEAD : obtention des entêtes
 - GET : obtention d'un document
 - TRACE : écho des données reçues par le serveur
 - etc.

Certaines informations sensibles, comme les cookies ou les authentifications basiques, sont envoyées dans les entêtes HTTP. La méthode TRACE les re-envoie donc vers le client.

Les vulnérabilités de type Cross Site Scripting permettent de faire exécuter du code dans le contexte d'un serveur web.

Lorsqu'un attaquant emploie une vulnérabilité de type Cross Site Scripting, il peut donc mener une requête TRACE vers le serveur.

Cette vulnérabilité permet ainsi à un attaquant d'obtenir des informations complémentaires suite à une attaque Cross Site Scripting.
Bulletin Vigil@nce complet... (Essai gratuit)

avis de vulnérabilité 3964

Suivi des sessions des utilisateurs

Synthèse de la vulnérabilité

Lorsque l'utilisateur a désactivé les cookies, un site web peut tout de même lui créer un profil en utilisant les entêtes ETag ou Last-Modified.
Produits concernés : HTTP (protocole).
Gravité : 1/4.
Conséquences : lecture de données.
Provenance : serveur internet.
Date création : 20/01/2004.
Date révision : 21/01/2004.
Références : V6-HTTPETAGLASTMODSES, VIGILANCE-VUL-3964.

Description de la vulnérabilité

Le protocole HTTP définit deux méthodes permettant de décider si un document web a été mis à jour depuis son dernier téléchargement.

La première consiste à utiliser les dates :
 - le serveur ajoute un entête Last-Modified indiquant la date de dernière modification du document
 - le client enregistre cette date, avec le document, dans son cache
 - lorsque le client désire à nouveau le document, il envoie une requête comme If-Modified-Since
 - le serveur indique alors si le client doit retélécharger la page ou non

La deuxième consiste à utiliser le contenu :
 - le serveur ajoute un entête ETag indiquant un haché du contenu du document
 - le client enregistre cette valeur, avec le document, dans son cache
 - lorsque le client désire à nouveau le document, il envoie une requête comme If-None-Matches
 - le serveur indique alors si le client doit retélécharger la page ou non

Si le serveur génère des valeurs Last-Modified ou Etag uniques pour chaque client, lorsque le client retournera les entêtes If-Modified-Since ou If-None-Matches le serveur pourra l'identifier. Il faut noter que cette attaque ne fonctionne que si la page est toujours dans le cache du navigateur.

Cette vulnérabilité permet donc à un site web de suivre les sessions des clients, même si les cookies sont désactivés.
Bulletin Vigil@nce complet... (Essai gratuit)
Notre base de données contient d'autres bulletins. Vous pouvez utiliser un essai gratuit pour les consulter.

Consulter les informations sur HTTP (protocole) :