<div class="gmail_quote">On Sun, Feb 14, 2010 at 6:34 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 Sat, Feb 13, 2010 at 11:47 AM, Mark Seaborn <<a href="mailto:mseaborn@chromium.org">mseaborn@chromium.org</a>> wrote:<br>
> On Sat, Feb 13, 2010 at 5:49 AM, Adam Barth <<a href="mailto:cap-talk@adambarth.com">cap-talk@adambarth.com</a>> wrote:<br>
</div><div class="im">>> Yes. Is there something specific you think would be better to<br>
>> recommend? In general, I wanted to point to things with RFCs in the<br>
>> "general recommendations" section.<br>
><br>
> Couldn't you recommend web-keys? Although I don't think there is an RFC for<br>
> web-keys.<br>
<br>
</div>I think it's better to be slightly general here. We're writing the<br>
document for the long term. Web-keys are one instance of the general<br>
concept, but they might seem archaic to a reader ten years from now if<br>
some other URL capability scheme catches on.<br></blockquote><div><br>Fair enough. You do mention secrets-in-URLs later in the document; maybe this should go in "general recommendations" too, if HTTP auth and client certs are mentioned in this section.<br>
</div><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"><br>
>> HTTP authentication has the virtue of better integrity protection than<br>
>> cookies. For example, there isn't a way (that I know of) for an<br>
>> active network attacker to force your HTTP auth credentials (at least<br>
>> <span class="__mozilla-findbar-search" style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">over</span> HTTPS), but there is a way to <span class="__mozilla-findbar-search" style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">over</span>write your cookies.<br>
><br>
> Are you saying there is a way for an active network attacker to <span class="__mozilla-findbar-search" style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">over</span>write<br>
> your cookies, even if you're using HTTPS?<br>
<br>
</div>Yes. An active network attacker can spoof an (unencrypted) HTTP<br>
response from the server and include a Set-Cookie header. Nothing in<br>
the protocol stops that from <span class="__mozilla-findbar-search" style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">over</span>writing cookies set <span class="__mozilla-findbar-search" style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">over</span> HTTPS.<br>
<div class="im"><br>
> Wouldn't this only work if the<br>
> client is not using HTTPS exclusively to connect to the server?<br>
<br>
</div>If the UA issues a single HTTP request, an active network attacker can<br>
spoof an HTTP redirect response and cause the UA to generate an HTTP<br>
request to the server. Now, if the user agent is configured to use<br>
Strict-Transport-Security for that host, there is some hope. :)<br></blockquote><div><br>Thanks for explaining. Is there a name for this attack? "Cookie overwriting" sounds appropriate (and you use this term in your paper), but Googling for this term doesn't produce many references.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="im">> Are there any consequences of <span class="__mozilla-findbar-search" style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">over</span>writing a cookie other than denial of<br>
> service?<br>
<br>
</div>Oh yes. Some of the worse consequences involve login CSRF like<br>
attacks. For more background, please see:<br>
<br>
<a href="http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf" target="_blank">http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf</a><br>
<br>
Essentially, by <span class="__mozilla-findbar-search" style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">over</span>writing the user's cookies with the attacker's<br>
cookies, the attacker causes the user to communicate with the server<br>
as if the user was the attacker. If the user communicates<br>
confidential information to the server (such as composing an email),<br>
that information will likely be stored in the attacker's account. For<br>
example, the attacker can look the "drafts" or "sent email" folder and<br>
read the user's confidential email.<br></blockquote><div><br>OK, so there are two kinds of cookie overwriting attack:<br> * cookie overwriting by hijacking an unencrypted HTTP connection<br> * cookie overwriting by "login CSRF"<br>
Is there a succinct term for the first that distinguishes it from the second?<br><br>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)?<br>
<br>My initial reaction was that overwriting-by-hijacking is not a CSRF or a confused deputy attack. Normally in CSRF, Alice (an attacker) makes a request and Bob's ambient credentials are applied. In the attacks above, Alice arranges it so that when Bob makes a request, Alice's credentials are applied.<br>
<br>Or to look at it a different way, the attack is enabled by Bob's failure to authenticate (or at least fully specify) the object he is
talking to. Bob thinks he's talking to (url, bob_cookie), but he's
actually talking to (url, alice_cookie).<br><br></div><div>On further reflection, CSRF is different from the classical confused deputy compiler example:<br> * In the compiler example, the attacker fully designates an object using a guessable filename in a global namespace. More fully designating the object does not solve the problem.<br>
* In CSRF, the attacker specifies an object using a guessable name that is relative to an account. More fully designating the object (using unguessable strings) is part of the fix. (I am assuming that an object is something that is account-specific here, which is not always true.)<br>
<br>Login CSRF consists of two steps:<br> * The attacker sends the login HTTP request.<br> * The innocent page uses the resulting overwritten cookies.<br>Which part is the CSRF? The first step looks like a CSRF, but since it's not using any credentials in the request, I suppose it is abusing the HTTP server's ambient authority to overwrite the browser's cookies.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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></blockquote><div><br>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.<br>
<br>I would call this attack a kind of spoofing, rather than CSRF. Rather than one site spoofing another, it can be one account or page spoofing another on the same site. Tyler's Petname toolbar would not help in this case. Maybe this can be addressed by petnames that are finer-grained than a
site, which might require sites' co-operation to establish.<br> </div><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"><br>
>> >> User agents can <span class="__mozilla-findbar-search" style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">miti</span>gate this issue to some degree by<br>
>> >> providing APIs for suppressing the Cookie header on outgoing<br>
>> >> requests.<br></div></blockquote><div><br>My problem with this statement is the agency it implies for user agents (no pun intended!). There are some security issues an individual user agent can address on its own, but this is not one of them.<br>
<br></div><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">
><br>
> I thought "to some degree" was a bit vague. Providing an API like UMP only<br>
> <span class="__mozilla-findbar-search" style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">miti</span>gates the issue if web apps use it. The issue is not so much that user<br>
> agents must be able to omit the cookie, but that servers must disregard the<br>
> presence or absence of cookies.<br>
<br>
</div>That's the exact argument I've been making in the CORS/UMP discussion<br>
in W3C WebApps, but MarkM and Tyler don't appear to agree with that<br>
point of view. Do you have a proposal for what we could say at that<br>
point the draft that would be less vague?<br></blockquote><div><br>You mean like in<br><a href="http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0155.html">http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0155.html</a>?<br>
<br>I'd still say that the best way to ensure that servers disregard the presence or absence of cookies is to ensure that new APIs don't send cookies.<br><br>How about: "Servers can <span class="__mozilla-findbar-search" style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">miti</span>gate this issue by disregarding the presence or absence of ambiently-provided credentials (including cookies) in requests and by using other authorising information instead. Standards bodies [or user agent implementors] can encourage this behaviour by providing user agent APIs that do not send ambient credentials in requests."<br>
<br></div><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"><br>
>> I've changed this to the following:<br>
>><br>
>> [[<br>
>> Servers SHOULD encrypt and sign their cookies when transmitting<br>
>> them to the user agent (even when sending the cookies <span class="__mozilla-findbar-search" style="padding: 0pt; background-color: yellow; color: black; display: inline; font-size: inherit;">over</span> a secure<br>
>> channel).<br>
>> ]]<br>
><br>
> It would be better to say that cookies should consist of encrypted/signed<br>
> data, or "servers should use cookies that are encrypted and signed".<br>
<br>
</div>This text seems to be the same as the above, but in the passive voice.<br></blockquote><div><br>Not exactly the same, because the passive voice adds ambiguity. :-)<br><br>C = encrypt(D, key)<br><br>C is the cookie.<br>
D is not a cookie.<br>The server encrypts D.<br>The server does not encrypt C.<br>D is encrypted (that is, D gets encrypted, but D does not consist of encrypted data).<br>C is encrypted (that is, C consists of encrypted data, but C does not get encrypted).<br>
<br>This is my interpretation, anyhow. :-)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="im">> Presumably if a server uses Swiss numbers for its cookies, there is no need<br>
> for the cookies to be encrypted and signed.<br>
<br>
</div>I presume you mean <<a href="http://wiki.erights.org/wiki/Swiss_number" target="_blank">http://wiki.erights.org/wiki/Swiss_number</a>>?<br></blockquote><div><br>Yes.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Indeed, these do not require encryption or signatures.</blockquote><div><br>You could change the text to cover this case by saying "Cookies should not be meaningful to any party other than the server. The server should ensure that cookies can only be interpreted by the server by either:<br>
* using randomly-generated numbers that are looked up in a table on the server [Swiss numbers], or<br> * encrypting and signing potentially-sensitive data to yield cookies."<br> <br>Cheers,<br></div>Mark<br><br></div>