Vigil@nce: HTTP, capturing a cookie
September 2008 by Vigil@nce
SYNTHESIS
An attacker can obtain a cookie which does not have the secure
attribute.
Gravity: 1/4
Consequences: data reading
Provenance: LAN
Means of attack: 1 attack
Ability of attacker: technician (2/4)
Confidence: unique source (2/5)
Diffusion of the vulnerable configuration: high (3/3)
Creation date: 23/09/2008
IMPACTED PRODUCTS
– HTTP
– HTTPS
– Unix - plateform
DESCRIPTION
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.
CHARACTERISTICS
Identifiers: VIGILANCE-VUL-8127