Re: _HttpOnly cookie prefix?

I like the idea! I think HttpOnly is an excellent security property of
cookies that's worth improving even more. I see the threat model as similar
to __Secure where it helps against attacks that exploit the fact that the
server has no visibility into how or when a cookie was set.

I agree that some conversation should be had about the overall approach of
piling on __Prefixes and whether there's some better alternative, but
unless anyone has a realistic idea of what that could look like I'd be
hesitant to block proposals that solve some real world problems on it.
Having these declared in the name has some positive side effects: It's
backwards-compatible, and it's a lot more difficult for servers to miss
checking the attribute that way.

So I'd love to see a proposal for this idea, personally.

Johann


On Wed, Feb 19, 2025 at 3:54 PM Rory Hewitt <rory.hewitt@gmail.com> wrote:

> 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
>