[cap-talk] Security considerations for cookies

[Mark Seaborn]

On Mon, Feb 15, 2010 at 3:35 PM, Adam Barth <w3c at adambarth.com> wrote:

> On Mon, Feb 15, 2010 at 6:05 AM, Mark Seaborn <mseaborn at chromium.org>
> wrote:
> > On Sun, Feb 14, 2010 at 6:34 PM, Adam Barth <w3c at adambarth.com> wrote:
>  >> Web-keys have the same login CSRF problems because the attacker can
> >> force the user's browser to navigate to the attacker's web-key.  Now,
> >> the user might not notice that they're interacting with the server
> >> under the attacker's authority.
> >
> > This attack can only work at a coarser granularity than login CSRF,
> though,
> > can't it?  The attack can only replace the whole page, whereas login CSRF
> > can violate the integrity of individual parts of the page during the
> page's
> > lifetime.
>
> Or maybe it works at a finer grain because I can replace pages in one
> tab but leave pages in other tabs unmolested.  In any case, the
> granularity of the attack doesn't matter.  The attack is still
> problematic.
>

What's not clear to me is which tabs you're saying the attacker can
navigate.  Suppose the browser has two tabs open:
 * Tab A:  https://webmail.com/users-webmail-webkey
 * Tab B:  https://attacker.com

The attacker controls tab B and can navigate it to
https://webmail.com/attacker-webmail-webkey, which is a "Compose Mail"
page.  When switching between tabs, the user mistakes this page as belonging
to their own webmail account and starts entering a draft e-mail there, which
the attacker can see.  This attack seems implausible because the attacker
does not know when the user is likely to want to compose an e-mail so does
not know when to redirect.  If "Compose Mail" pages appear unexpectedly the
user would get suspicious.  If the attacker redirects to an "Inbox" page,
information that only the user can see will be missing, so won't that be a
giveaway?

Are you saying that the attacker can also cause tab A to navigate to an
attacker-supplied web-key?


> Can't these attacks be addressed by the usual means of including a
> suitably
> > unguessable secret in the URL or POST parameter (which can be checked
> > against the cookie if you want to protect against URL leaks)?
>
> Nope.  Recall, that we're worried about an attack who uses these
> integrity failures to transplant cookies from his browser to the
> user's browser.  He can just as easily transplant the "unguessable"
> secret he receives in his browser to the user's browser in the URL or
> POST parameters.
>

Doesn't that involve navigating the user's browser tab as well?

Without navigating a tab, I thought the potential vulnerability was
something like the following:

Suppose the user has a tab open on "https://webmail.com/compose-mail".  An
attacker uses an active network attack to replace the user's browser's
cookie for webmail.com.  If the "Compose Mail" page is sending drafts back
to the server by posting them to "https://webmail.com/save-draft", they will
be saved to the attacker's account.  But if the page instead posts to "
https://webmail.com/save-draft?secret-id", the server can check that
secret-id corresponds to the cookie, and ignore the request if it doesn't.
How can the attacker replace the secret-id that the page is using, without
navigating the tab?

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20100217/7097ce0b/attachment.html