Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Handling cookies is a minefield

grayduck.mn

Post reply on HN
Print view View original

31–40 of 270 posts

Re: Handling cookies is a minefield

#31

Post by rendall »

Sohcahtoa82 wrote: post #28
jeffrallen wrote: post #13

The article mocks Postel's law, but if the setter of the cookie had been conservative in what they sent, there would have been no need for the article...

> The article mocks Postel's law As they should. Postel's Law was a terrible idea and has created minefields all over the place. Sometimes, those mines aren't just bugs, but create gaping security holes. If your client is sending data that doesn't conform to spec, you have a bug, and you need to fix it. It should never be up to the server to figure out what you meant and accept it.

[flagged]

Re: Handling cookies is a minefield

#32

Post by layer8 »

cruffle_duffle wrote: post #15
AshleysBrain wrote: post #12

Cookies seem to be a big complicated mess, and meanwhile are almost impossible to change for backwards-compatibility reasons. Is this a case to create a new separate mechanism? For example a NewCookie mechanism could be specified instead, and redesigned from the ground-up to work consistently. It could have all the modern security measures built-in, a stricter specification, proper support for unicode, etc.

Needs a better name than NewCookie though. Suggestions include SuperCookie, UltraCookie or BetterCookie Or to be slightly more serious avoid calling it a cookie and call it something else. Too much baggage surrounding the word cookie.

TrickOrTreat would seem appropriate.

Re: Handling cookies is a minefield

#33

Post by pimlottc »

anamexis wrote: post #30
remram wrote: post #8

Earlier quoted context omitted.

Quotes in the value when quotes delimit the value? Yeah that seems dangerous to me.

Quotes don't delimit the value.

Per the section 4.1.1 rules quoted in the article, cookie values can be optionally quoted:

> cookie-value = cookie-octet / ( DQUOTE cookie-octet DQUOTE )

Re: Handling cookies is a minefield

#35

Post by bob1029 »

AshleysBrain wrote: post #12

Cookies seem to be a big complicated mess, and meanwhile are almost impossible to change for backwards-compatibility reasons. Is this a case to create a new separate mechanism? For example a NewCookie mechanism could be specified instead, and redesigned from the ground-up to work consistently. It could have all the modern security measures built-in, a stricter specification, proper support for unicode, etc.

The DOM & URL are the safest places to store client-side state. This doesn't cover all use cases, but it does cover the space of clicking pre-authorized links in emails, etc.

I spend a solid month chasing ghosts around iOS Safari arbitrarily eating cookies from domains controlled by our customers. I've never seen Google/Twitter/Facebook/etc domains lose session state like this.

Re: Handling cookies is a minefield

#36

Post by bell-cot »

cruffle_duffle wrote: post #15
AshleysBrain wrote: post #12

Cookies seem to be a big complicated mess, and meanwhile are almost impossible to change for backwards-compatibility reasons. Is this a case to create a new separate mechanism? For example a NewCookie mechanism could be specified instead, and redesigned from the ground-up to work consistently. It could have all the modern security measures built-in, a stricter specification, proper support for unicode, etc.

Needs a better name than NewCookie though. Suggestions include SuperCookie, UltraCookie or BetterCookie Or to be slightly more serious avoid calling it a cookie and call it something else. Too much baggage surrounding the word cookie.

His Majesty's English might suggest "biscuit".

Re: Handling cookies is a minefield

#37

Post by SilasX »

Sohcahtoa82 wrote: post #28
jeffrallen wrote: post #13

The article mocks Postel's law, but if the setter of the cookie had been conservative in what they sent, there would have been no need for the article...

> The article mocks Postel's law As they should. Postel's Law was a terrible idea and has created minefields all over the place. Sometimes, those mines aren't just bugs, but create gaping security holes. If your client is sending data that doesn't conform to spec, you have a bug, and you need to fix it. It should never be up to the server to figure out what you meant and accept it.

You could split the difference with a 397 TOLERATING response, which lets you say "okay I'll handle that for now, but here's what you were supposed to do, and I'll expect that in the future". (j/k it's an April Fool's parody)

https://pastebin.com/TPj9RwuZ

Re: Handling cookies is a minefield

#38

Post by echelon »

juped wrote: post #7
kibwen wrote: post #6

The article mentions Rust's approach, but note that (unlike the other mentioned languages) Rust doesn't ship any cookie handling facilities in the standard library, so it's actually looking at the behavior of the third-party "cookie" crate (which includes the option to percent-encode as Ruby does): https://docs.rs/cookie/0.18.1/cookie/

De facto standardization by snapping up good names early!

Not really. A lot of essential third party Rust crates and projects have "weird" names, eg. "nom", "tokio", etc. You can see that from the list of most downloaded crates [1].

This one just happens to have been owned and maintained by core Rust folks and used in a lot of larger libraries. This is more the exception than the rule.

It's a given that you should do due diligence on crates and not just use the first name that matches your use case. There's a lot of crate name squatting and abandonware.

Rust crates need namespacing to avoid this and similar problems going forward.

[1] https://crates.io/crates?sort=downloads

Re: Handling cookies is a minefield

#39

Post by robgibbons »

0x073 wrote: post #19

IT IS a mess, but I never saw json inside a cookie. For json I use local storage or indexeddb.

In both cases (cookie vs localStorage) you're really just storing your data as a string value, not truly a JSON object, so whether you use a cookie or localStorage is more dependent on the use case.

If you only ever need the stored data on the client, localStorage is your pick. If you need to pass it back to the server with each request, cookies.

Re: Handling cookies is a minefield

#40

Post by klysm »

jmull wrote: post #26

> minefield Cookies are a bit of a mess, but if you're going to use them, you can follow the standard and all will be well. Not so much a minefield, but a hammer; you just need to take some care not to hit yourself on the thumb. I guess the confusion here is that the browser is taking on the role of the server in setting the cookie value. In doing so it should follow the same rules any server should in setting a cook…

I don’t understand how that’s not a minefield, it’s easy to go astray?
Post reply on HN