The Vigil@nce team watches public vulnerabilities impacting your computers, and then offers security solutions, a database and tools to fix them.

Computer vulnerabilities of Protocol HTTP

computer vulnerability bulletin 20428

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

Synthesis of the vulnerability

An attacker can act as a Man-in-the-Middle when an HTTP proxy is configured, in order to obtain passwords of users of this proxy.
Impacted products: HTTP protocol, SSL protocol.
Severity: 1/4.
Consequences: data reading, data creation/edition.
Provenance: intranet server.
Creation date: 18/08/2016.
Identifiers: FalseCONNECT, VIGILANCE-VUL-20428, VU#905344.

Description of the vulnerability

When an HTTP proxy is configured, the web browser uses the HTTP CONNECT method to ask the proxy to setup a secured TLS session.

However, the HTTP CONNECT query and its reply are sent in a clear HTTP session. An attacker can act as a Man-in-the-Middle, and spoof a 407 Proxy Authentication reply to the client. The victim then sees an authentication windows, and may enter his password, which is sent to the attacker's server.

It can be noted that this vulnerability impacts all session types requested to the proxy, but as the victim requests an https/TLS url, he expects his session to be encrypted. It is thus a perception problem, instead of a real new vulnerability.

An attacker can therefore act as a Man-in-the-Middle when an HTTP proxy is configured, in order to obtain passwords of users of this proxy.
Full Vigil@nce bulletin... (Free trial)

computer vulnerability 17985

HTTPS: Cookie injection

Synthesis of the vulnerability

An attacker can inject a cookie in an HTTPS (HTTP+TLS) session, in order to alter the behavior of the web service, if it is not conceived to receive unexpected cookies.
Impacted products: Chrome, Edge, IE, Firefox, SeaMonkey, Opera, HTTP protocol.
Severity: 1/4.
Consequences: data creation/edition.
Provenance: internet server.
Creation date: 25/09/2015.
Identifiers: VIGILANCE-VUL-17985, VU#804060.

Description of the vulnerability

Cookies (RFC 6265) are additional HTTP headers defined by web servers, and then returned by the client when it accesses again to this web server.

However, the RFC 6265 does not request web browsers to send the cookie through the same canal where it came from. So :
 - the http://example.com/ site (or an attacker spoofing this server) can define a cookie, which will be sent to http://other.example.com/ and https://other.example.com/
 - the http://www.example.com/ site (or an attacker spoofing this server) can define a cookie with the "secure" flag, which will be sent to https://www.example.com/

An attacker can therefore inject a cookie in an HTTPS (HTTP+TLS) session, in order to alter the behavior of the web service, if it is not conceived to receive unexpected cookies.
Full Vigil@nce bulletin... (Free trial)

computer vulnerability alert 8726

HTTP: incoherent handling of parameters

Synthesis of the vulnerability

The HTTP protocol does not define the behavior of web servers when a request contains the same variable several times, which can generate vulnerabilities.
Impacted products: HTTP protocol, Unix (platform) ~ not comprehensive.
Severity: 1/4.
Consequences: data reading, data creation/edition, data flow.
Provenance: internet client.
Creation date: 20/05/2009.
Revision date: 12/06/2009.
Identifiers: BID-35323, VIGILANCE-VUL-8726.

Description of the vulnerability

The RFC 2616 defines the HTTP protocol. The RFC 3986 defines the syntax of uris. For example:
  http://server/page?var1=val1&var2=val2
Both RFC do not define how to handle urls containing several times the same variable name. For example:
  http://server/page?var=val1&var=val2

Developers of HTTP service thus made different choices:
 - ASP.NET : the value is the concatenation of parameters ("val1,val2")
 - PHP : the value is the last parameter ("val2")
 - JSP : the value is the first parameter ("val1")
 - Zope : the value is an array (['val1', 'val2'])

Similarly, if a parameter is defined in the Query String and in a Cookie, behavior diverge. For example:
  POST /page?var=val1
  Cookie: var=val2
  \n
  var=val3

An attacker can therefore use these incoherent behavior in order to bypass an IDS or web filtering modules.

Theses vulnerabilities were named HPP (HTTP Parameter Pollution).
Full Vigil@nce bulletin... (Free trial)

computer vulnerability announce CVE-2008-3663

HTTP: capturing a cookie

Synthesis of the vulnerability

An attacker can obtain a cookie which does not have the secure attribute.
Impacted products: Fedora, openSUSE, HTTP protocol, SSL protocol, RHEL, SLES, Unix (platform) ~ not comprehensive.
Severity: 1/4.
Consequences: data reading.
Provenance: LAN.
Creation date: 23/09/2008.
Identifiers: 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 of the vulnerability

The HTTP protocol defines cookies:
 - the server returns a cookie to the client
 - the client sends this cookie for each new connection to the server

For example:
 - the client connects to https://server/page1 and obtains a cookie
 - the client connects to https://server/page2 and sends this cookie
 - the client connects to http://server/page3 and sends this cookie
The cookie was obtained in a secured session ("https://" = HTTP on SSL) of the page1, and is sent for page 3 as "http://", which means that it flows in clear form on the network. To forbid this behavior, the "secure" attribute of a cookie indicates that it can only be used in the SSL session.

Some services do not use the "secure" attribute, because every connection to the port 80/http is redirected to the port 433/https, and thus developers think that the port 80 is never used. However, victims connect to the port 80 (or are redirected by an attacker via a 301 permanent redirect). The cookie thus flows in clear form (port 80) before flowing in the SSL session (port 443).

This vulnerability notably impacts SquirrelMail.
Full Vigil@nce bulletin... (Free trial)

computer vulnerability announce CVE-2005-0175 CVE-2005-2090

HTTP : injection de réponses

Synthesis of the vulnerability

Un attaquant peut injecter des données dans une requête HTTP dans le but de produire deux ou plusieurs réponses HTTP.
Impacted products: Debian, Fedora, HP-UX, WebSphere AS Traditional, Mandriva Linux, IIS, ISA, NetCache, openSUSE, Oracle iPlanet Web Server, WebLogic, HTTP protocol, RHEL, RedHat Linux, Squid, TurboLinux.
Severity: 1/4.
Consequences: data flow.
Provenance: document.
Number of vulnerabilities in this bulletin: 3.
Creation date: 05/03/2004.
Revisions dates: 09/03/2004, 25/01/2005.
Identifiers: 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 of the vulnerability

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)
Full Vigil@nce bulletin... (Free trial)

computer vulnerability bulletin CVE-2004-2320 CVE-2005-3398

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

Synthesis of the vulnerability

La méthode HTTP TRACE permet d'obtenir des compléments d'informations suite à une attaque de type Cross Site Scripting.
Impacted products: Apache httpd, HPE BSM, HP-UX, Domino, IIS, IE, Oracle iPlanet Web Server, Solaris, Trusted Solaris, WebLogic, HTTP protocol, Sun AS.
Severity: 1/4.
Consequences: client access/rights.
Provenance: document.
Number of vulnerabilities in this bulletin: 2.
Creation date: 23/01/2003.
Revisions dates: 24/01/2003, 27/01/2003, 13/02/2003, 05/05/2003, 08/09/2003, 27/01/2004, 04/11/2004.
Identifiers: 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 of the vulnerability

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.
Full Vigil@nce bulletin... (Free trial)

vulnerability note 3964

Suivi des sessions des utilisateurs

Synthesis of the vulnerability

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.
Impacted products: HTTP protocol.
Severity: 1/4.
Consequences: data reading.
Provenance: internet server.
Creation date: 20/01/2004.
Revision date: 21/01/2004.
Identifiers: V6-HTTPETAGLASTMODSES, VIGILANCE-VUL-3964.

Description of the vulnerability

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.
Full Vigil@nce bulletin... (Free trial)
Our database contains other pages. You can request a free trial to read them.

Display information about Protocol HTTP: