On Wed, Feb 19, 2025 at 9: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).
>
This is *exactly* the scenario I'm trying to prevent with this. Thanks!
>
> -Dan Veditz
>