Re: _HttpOnly cookie prefix?

Yeah, I was trying to be 'nice' about the "Was it a hack added after the
fact?" bit... :)

> Don't servers rely on cookies to know if they've even had a previous
interaction with that client?

I would *assume* that a server which is having an ongoing session with a
client (FSVO 'session') would have sent multiple cookies using Set-Cookie
headers, including a 'session id' cookie. So when it receives a request
from a client which passes a session ID cookie, it looks it up in some
database or whatever, 'restarts' the session and can (and *should*!) check
which cookies it previously sent to the browser, which ones it expects to
see, etc. At least, that, to me, is how the software should be written.

> But if there wasn't already an existing HttpOnly cookie then the client
can create one [...]

That was what I meant - I was very unclear.

I also agree with Anne's points, and I'm not sure how the various
__Secure-* and __Host-* cookies would play with __HttpOnly-* cookies
proposed by Yoav. Would this end up with cookie names like
"__HttpOnly__Secure-string"?

Rory


On Wed, Feb 19, 2025 at 12:32 PM Daniel Veditz <dveditz@mozilla.com> wrote:

> On Wed, Feb 19, 2025 at 10:12 AM Rory Hewitt <rory.hewitt@gmail.com>
> wrote:
>
>> First, I personally don't like the use of the double-underscore prefixes
>> - [...] it feels like (is?) a hack that was added after the cookie
>> mechanism was created.
>>
>
> The prefixes were ABSOLUTELY a hack added after the fact.
>
> Wouldn't the server *know* whether or not it had created a given cookie
>> during a previous interaction with the client? I would think the server
>> should be keeping track of this...?
>>
>
> Don't servers rely on cookies to know if they've even had a previous
> interaction with that client? One of the worst things about cookies is that
> attributes aren't returned, and a server never knows whether the "foo"
> cookie it sees is the one it thinks it is; it could be from a different
> path or domain, or wholly invented on the client side (e.g. a
> session-fixation attack).
>
>
>> Or is your concern about a malicious client updating an existing cookie
>> that was originally created via a "Set-Cookie" header sent form the server?
>>
>
> That, at least, shouldn't be a problem. User Agents aren't supposed to
> allow creating or updating an HttpOnly cookie (see steps 10 and 11.2 of
> https://www.rfc-editor.org/rfc/rfc6265.html#section-5.3).
>
> But if there wasn't already an existing HttpOnly cookie then the client
> can create one and the server has no way to know it's not an HttpOnly one
> the server created on an earlier visit (see "One of the worst things about
> cookies" above).
>
> -Dan Veditz
>


-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt