<<< Date Index >>>     <<< Thread Index >>>

Third party cookie handling in Opera can lead to potential compromises in Servers relying on redirection

Hi,
 Opera's policy with respect to third party cookie makes it vulnerable to
session replay attacks. This was discovered 2 weeks back. Opera's response
to the same is attached. The issue and the workaround are listed below.

Opera claims to be the fastest browser on earth and has the third largest
user base.

Issue:
In case Opera privacy policy is set to refuse all third party cookies, some
servers (one is mail.yahoo.com) become susceptible to session replay
attacks. Reproduction steps, for mail.yahoo.com are:
1. set third party cookie handling to refuse all third party cookies.
2. login to your yahoo mail account.
3. sign out. 
4. Check the cookies using opera cookie manager. The cookies 'T' and 'Y' are
set to expire in 1970. 
5. Change the same to sometime in the future. 
6. In the address bar, type mail.yahoo.com, you will be in the last account
without needing username or password.

Yahoo is not maintaining a session at its end and is relying entirely on
cookies for session information. This leads to a session replay attack for
Opera users at public computers, cyber cafes etc. IE/firefox/mozilla work
fine. This can be reproduced for any network community which is relying on
cookies alone for session management across a host of its services [mail,
chat etc]

Cause:
This is so because for the domain (mail.yahoo.com) the above said two
cookies are not deleted/overwritten at logout if third party cookie handling
is set to refuse all third party cookies. According to Opera, This is so
because
"
cookies for the URL because it is considered a thirdparty
server (f533.mail.yahoo.com != yahoo.com). This is based on
the RFC 2109 (sec. 4.3.5) and RFC 2965 (sec. 3.3.6) definition
of "unverifiable transactions", which includes redirection.

RFC 2965:

  An unverifiable transaction is to a third-party host if its request-
  host U does not domain-match the reach R of the request-host O in the
  origin transaction.

  When it makes an unverifiable transaction, a user agent MUST disable
  all cookie processing (i.e., MUST NOT send cookies, and MUST NOT
  accept any received cookies) if the transaction is to a third-party
  host.
"

So, according to Opera, it's a case of correct implementation of RFC causing
a compromise for the users. It all depends on what can be classified as
unverifiable transaction.
        Shouldn't this still be fixed either by Yahoo or by Opera for better
security of customers?

Work arounds are several:
1. Allow third party cookies.
2. Set Opera to delete all private data at the time of closure.

Credits:
Rohit Dube.

Thanx
Rohit Dube
KritiKal Solutions Private Limited
TB1,TBIU,
Block One Extension, 
IIT Delhi,
New Delhi - 110017
India.

----The reader this message encounters not failing to understand is
cursed.----
--- Begin Message ---
Title: Fwd: Cookie handling in opera, third party cookies.

---------- Forwarded message ----------
From: bug-149095-s264@xxxxxxxxxxxxxx <bug-149095-s264@xxxxxxxxxxxxxx>
Date: Mon, 16 Aug 2004 10:32:15 +0200
Subject: Re: Cookie handling in opera, third party cookies.
To: rddube@xxxxxxxxx

På Mon, 16 Aug 2004 10:36:16 +0530, skrev <bug-149095-reporter@xxxxxxxxxxxxxx>:

> I checked further, this is not a problem with yahoo.This is a case of faulty cookie handling by Opera incase of redirects.

 This is by design, and it _is_ a problem with Yahoo,
just not an obvious one.  See below.

Since redirects are not triggered by the user, they are
treated in the same way as inline elements (img, etc.)
from other servers.

I qoute a comment from the developer for more detail:

'... the login.yahoo server will NEVER send a "delete cookie"
message because it does not know that the client have any
cookies it should delete.

And the reason it does not know is that Opera has disabled
cookies for the URL because it is considered a thirdparty
server (f533.mail.yahoo.com != yahoo.com). This is based on
the RFC 2109 (sec. 4.3.5) and RFC 2965 (sec. 3.3.6) definition
of "unverifiable transactions", which includes redirection.

RFC 2965:

  An unverifiable transaction is to a third-party host if its request-
  host U does not domain-match the reach R of the request-host O in the
  origin transaction.

  When it makes an unverifiable transaction, a user agent MUST disable
  all cookie processing (i.e., MUST NOT send cookies, and MUST NOT
  accept any received cookies) if the transaction is to a third-party
  host.

The reason it becomes a "problem" for Opera users is that we have
different (and stricter) definition of what is a thirdparty server
than MSIE (we include redirects), but considering MSN's use of a
centralized GUID server this may be understandable.

We cannot "fix" this problem without breaking our thirdparty
cookie handling.

The shared computer scenario can be avoided by the user using
"Delete Private Data" before leaving the computer.

The real problem here is that yahoo will accept any login-id
cookie it have ever set (or a reasonable approximation) even
AFTER it has told the client to delete the cookie. This means
that anyone listening in to a logged in yahoo connection and
grabs the cookies will be able to log into that user's account
without having the password.

Yahoo can solve the problem by first going to login.yahoo,
then clean up the mail.yahoo cookies afterwards.

They can further reduce the problem by securing their login
system against replay attacks, especially after the user has
logged out.'

--
Herman Robak,
Opera Software


--- End Message ---