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

241–250 of 270 posts

Re: Handling cookies is a minefield

#241

Post by bloppe »

pjc50 wrote: post #215
0xbadcafebee wrote: post #61

Did anyone else notice that the HTTP protocol embeds within it ten-thousand different protocols? Browsers and web servers both "add-on" a ton of functionality, which all have specifications and de-facto specifications, and all of it is delivered through the umbrella of basically one generic "HTTP" protocol. You can't have the client specify what version of these ten-thousand non-specifications it is compatible with,…

Anarchy is the price to pay for not having a monopoly dictate a nice clean spec which they can force-deprecate whenever they want.

There's no differences between a monopoly and an open standard when it comes to breaking users. They both would rather not for the same reasons

Re: Handling cookies is a minefield

#242

Post by brabel »

lknuth wrote: post #196
vbezhenar wrote: post #187

Earlier quoted context omitted.

They are not the only place to store tokens. You can store tokens with localStorage for JS-heavy website, in fact plenty of websites do that. It's not as secure, but acceptable. Another alternative is to "store" token in URL, it was widely used in Java for some reason (jsessionid parameter).

To expand on the "not as secure" comment: local storage is accessible to every JS that runs in the context of the page. This includes anything loaded into the page via like tracking or cookie consent services.

And I feel like it's important to expand on the fact that Cookies are visible to JS by default as well, except if the Cookie has the `HttpOnly` attribute set. Obviously, for auth, you absolutely want the session cookie to have both the `Secure` and `HttpOnly` attributes.

See https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#bl...

Re: Handling cookies is a minefield

#243

Post by dgoldstein0 »

maxwellg wrote: post #107

Cookies are filled with weird gotchas and uncomfortable behavior that works 99.95% of the time. My favorite cookie minefield is cookie shadowing - if you set cookies with the same name but different key properties (domain, path, etc.) you can get multiple near-identical cookies set at once - with no ability for the backend or JS to tell which is which. Try going to https://example.com/somepath and entering the follow…

Yep it's hella fraught. https://www.usenix.org/conference/usenixsecurity15/technical... goes into detail about this problem and related headaches

Re: Handling cookies is a minefield

#244

Post by jonchurch_ »

bazzargh wrote: post #226
maxwellg wrote: post #107

Cookies are filled with weird gotchas and uncomfortable behavior that works 99.95% of the time. My favorite cookie minefield is cookie shadowing - if you set cookies with the same name but different key properties (domain, path, etc.) you can get multiple near-identical cookies set at once - with no ability for the backend or JS to tell which is which. Try going to https://example.com/somepath and entering the follow…

btw, technically that leading dot in the domain isn't allowed and will be ignored; https://www.rfc-editor.org/rfc/rfc6265#section-4.1.2.3 ... this came up recently after I tightened the validation in jshttp/cookie https://github.com/jshttp/cookie/pull/167 - since that PR the validation has been loosened again a bit, similar to the browser code mentioned in the article. My changes were prompted by finding a bug in our…

This is one of those things where specs are still hard to parse.

It is considered invalid syntax to lead with a dot by the rules. But it also must be ignored if present. Its lacking a “MUST NOT” because the spec is defining valid syntax, while also defining behavior for back compat.

It would break too many things to throw here or serialize while ignoring the leading dot. Leading dots are discouraged, but shouldnt break anyone following the spec. Maybe a warn log in dev mode if serializing a domain with dot, to try and educate users. Dunno its worth it though.

The point of jshttp IMO is to smooth over these kinds of nuances from spec updates. So devs can get output which is valid in as many browsers as possible without sacrificing functionality or time studying the tomes.

Re: Handling cookies is a minefield

#245

Post by EasyMark »

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!

Would “rookie” be the obvious name in that case?

Re: Handling cookies is a minefield

#246

Post by 0x073 »

withinboredom wrote: post #209
0x073 wrote: post #174

Earlier quoted context omitted.

Httponly cookie is the way, but then you just don't use json as cookie value that is send on every request. Csrf is no problem as the data from service worker is only active on the site itself. If you speak about csrf with a website where you can't trust js, you're site is broken as xhr/fetch use the same httponly cookies and is affected as well.

Since when can you trust js?

Big websites use js and if they leak most of the time it's not a js issue.

I think the distrust of js is a personal issue.

Re: Handling cookies is a minefield

#247

Post by ndusart »

marcosdumay wrote: post #230
ndusart wrote: post #202

Earlier quoted context omitted.

So, just be as conservative as possible when you produce data and as liberal as possible when you receive something. Your code will then require the least cooperation from *any* other code to be compatible with. Doing otherwise will require cooperation to adjust on the specificities clients expect, and you fall into the trap of the prisoner dilemna.

No, when you create a protocol define exactly what you need what is optional and what is an error, and stick to that. Being liberal on what you accept is a path for disaster.

You changed the problem. Postel's law is not about writing the protocol but implementing it.

Sure, protocol should be designed to be as specific as possible but unfortunately these are not always defined up to that point for any good or bad reasons, and we generally are at best just in the implementation side and cannot influence the writing of the protocol, so the Postel's law is the best we can apply to avoid having to cooperate with the rest of the planet.

Re: Handling cookies is a minefield

#248

Post by qingcharles »

echelon wrote: post #120
Dilettante_ wrote: post #112

Earlier quoted context omitted.

A reference to Tokio Hotel was not on my HN bingo card

This is the first time Tokio Hotel has been mentioned on HN in over ten years. https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... That has me thinking of Neutral Milk Hotel. Totally different vibes.

Thank you for doing the background work. Wild they've never been mentioned before. And this time, not in relation to their music...

Re: Handling cookies is a minefield

#249

Post by teaearlgraycold »

jan_g wrote: post #191
anonfordays wrote: post #181

Earlier quoted context omitted.

Just use subdomains such as *.dev.example.com, *.test.example.com, *.prod.example.com, etc., no?

We have *.example.dev, *.example.qa, *.example.com for development, staging/qa and production. Works well and we haven't had any issues with cookies.

This works fine and is what I’ve done. But if you’re sending email from those domains or working with enterprise customers using the same TLD will be helpful.

Re: Handling cookies is a minefield

#250

Post by bazzargh »

jonchurch_ wrote: post #244
bazzargh wrote: post #226

Earlier quoted context omitted.

btw, technically that leading dot in the domain isn't allowed and will be ignored; https://www.rfc-editor.org/rfc/rfc6265#section-4.1.2.3 ... this came up recently after I tightened the validation in jshttp/cookie https://github.com/jshttp/cookie/pull/167 - since that PR the validation has been loosened again a bit, similar to the browser code mentioned in the article. My changes were prompted by finding a bug in our…

This is one of those things where specs are still hard to parse. It is considered invalid syntax to lead with a dot by the rules. But it also must be ignored if present. Its lacking a “MUST NOT” because the spec is defining valid syntax, while also defining behavior for back compat. It would break too many things to throw here or serialize while ignoring the leading dot. Leading dots are discouraged, but shouldnt bre…

I do sympathise somewhat with that view, but I disagree. To be valid in as many browsers as possible, and as many back-end systems too, serialize() would have to take the _narrowest_ view of the spec possible. If you make cookies that stray from the spec, you cannot know if they will work as intended when they are read, you've baked in undefined behaviour. It's not just browsers; in our systems we have myriad backends that read the cookies that are set by other microservices, that could be reading them strictly and dropping the non-conformant values.

If you want to set invalid cookie headers, it's very easy to do so, I just don't think you should expect a method that says it will validate the values to do that.

The dot I can go along with because the behaviour is defined, but I'm less comfortable that a bunch of other characters got re-added a couple of days ago. As for smoothing over nuances from spec updates...the RFC has been out there for 13 years, and jshttp/cookie has only been around for 12; there have been no updates to smooth, it has just never validated to the spec.

Post reply on HN