<div class="gmail_quote">On Mon, Feb 15, 2010 at 3:35 PM, Adam Barth <span dir="ltr"><<a href="mailto:w3c@adambarth.com">w3c@adambarth.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Mon, Feb 15, 2010 at 6:05 AM, Mark Seaborn <<a href="mailto:mseaborn@chromium.org">mseaborn@chromium.org</a>> wrote:<br>
> On Sun, Feb 14, 2010 at 6:34 PM, Adam Barth <<a href="mailto:w3c@adambarth.com">w3c@adambarth.com</a>> wrote:<br>
</div><div class="im">
</div><div class="im">
>> Web-keys have the same login CSRF problems because the attacker can<br>
>> force the user's browser to navigate to the attacker's web-key. Now,<br>
>> the user might not notice that they're interacting with the server<br>
>> under the attacker's authority.<br>
><br>
> This attack can only work at a coarser granularity than login CSRF, though,<br>
> can't it? The attack can only replace the whole page, whereas login CSRF<br>
> can violate the integrity of individual parts of the page during the page's<br>
> lifetime.<br>
<br>
</div>Or maybe it works at a finer grain because I can replace pages in one<br>
tab but leave pages in other tabs unmolested. In any case, the<br>
granularity of the attack doesn't matter. The attack is still<br>
problematic.<br></blockquote><div><br>What's not clear to me is which tabs you're saying the attacker can navigate. Suppose the browser has two tabs open:<br> * Tab A: <a href="https://webmail.com/users-webmail-webkey">https://webmail.com/users-webmail-webkey</a><br>
* Tab B: <a href="https://attacker.com">https://attacker.com</a><br><br>The attacker controls tab B and can navigate it to <a href="https://webmail.com/attacker-webmail-webkey">https://webmail.com/attacker-webmail-webkey</a>, 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?<br>
<br>Are you saying that the attacker can also cause tab A to navigate to an attacker-supplied web-key?<br><br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
> Can't these attacks be addressed by the usual means of including a suitably<br>
> unguessable secret in the URL or POST parameter (which can be checked<br>
> against the cookie if you want to protect against URL leaks)?<br><br>Nope. Recall, that we're worried about an attack who uses these<br>
integrity failures to transplant cookies from his browser to the<br>
user's browser. He can just as easily transplant the "unguessable"<br>
secret he receives in his browser to the user's browser in the URL or<br>
POST parameters.<br></blockquote>
<br>Doesn't that involve navigating the user's browser tab as well?<br><br>Without navigating a tab, I thought the potential vulnerability was something like the following:<br><br>Suppose the user has a tab open on "<a href="https://webmail.com/compose-mail">https://webmail.com/compose-mail</a>". An attacker uses an active network attack to replace the user's browser's cookie for <a href="http://webmail.com">webmail.com</a>. If the "Compose Mail" page is sending drafts back to the server by posting them to "<a href="https://webmail.com/save-draft">https://webmail.com/save-draft</a>", they will be saved to the attacker's account. But if the page instead posts to "<a href="https://webmail.com/save-draft?secret-id">https://webmail.com/save-draft?secret-id</a>", 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?<br>
<br>Mark<br><br></div></div>