Software Engineering Institute

HTTP cookies are text that is sent to a client web browser from a server. Cookies are transmitted back to the server from the client's browser when the client accesses the web site.

Some web sites may authenticate users with a username and password, create a cookie with a unique identifier (a shared secret), then answer future authentication requests with the cookie. To increase security, the web site may delete the cookie when the user logs out, enable the optional "Secure" attribute for the "Set-Cookie" response header, or have the cookie to expire after a specific date. Web browser toolbars or extensions may also send authentication credentials (cookies) to web sites or services.

Web sites that use cookies for authentication over plain text protocols like HTTP are vulnerable to an authentication bypass vulnerability, even if the initial login credentials are sent to the server using an encrypted protocol. If an attacker can intercept traffic that contains the cookie, the attacker may be able to replicate or replay the cookie that is being used as authentication credentials. In particular, sites that provide "software as a service" are often affected by this type vulnerability.

Null encryption is a valid option when using HTTPS according to the original SSL specifications. We are unaware of any vendors that implement the HTTPS protocol that do not use encryption.

A remote unauthenticated attacker who can intercept traffic that is destined to an affected web site may be able to take any action on the web site that the legitimate user can.

There are a number of options that can mitigate this type of vulnerability. Please see the Workarounds and Systems Affected sections of this document for more information, including information about specific vendors.

Workarounds for users

• Accessing the web site using encrypted HTTPS may mitigate this vulnerability. Note that the entire session, not just the initial username and password, will need to be encrypted . For this workaround to be completely effective, the secure attribute must be set on the cookie.

• Logging off from the web service may reduce the amount of time an attacker has to obtain credentials and exploit unprotected services.

• Users who can encrypt sensitive data locally by using PGP or GnuPG, password protected ZIP files, or other types of encryption before storing it on a web site may be able restrict what information an attacker can obtain by exploiting this vulnerability. Note that this workaround may not be feasible for all services offered by all vendors.

• The NoScript Firefox extension may mitigate these types of vulnerabilities by forcing specified websites to use HTTPs and by setting the secure attribute on cookies used by those sites. See the NoScript faq for more information.
  
• Evaluate the risks of accessing vulnerable sites before using the services while connected to untrusted networks.

• Provide the ability for users to access the site using HTTPS, or at a minimum only transmit authentication credentials over HTTPS. For this workaround to be completely effective, the secure attribute must be set on the cookie. See section 4.2.2 of RFC 2109 for more details.