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

261–270 of 270 posts

Re: Handling cookies is a minefield

#261

Post by jmull »

rcxdude wrote: post #251
jmull wrote: post #236

> ...tragedy of following Postel's Law. The "law" is: "Be liberal in what you accept, and conservative in what you send." But here the problem is caused by being liberal in what is sent while being more conservative in what is accepted. It's using invalid characters in the cookie value, which not everything can handle. Following Postel's law would have avoided the problem.

Postel's law is the main reason why there are so many cases where something is being liberal in what it sends. It's a natural approach when trying to enter into an existing ecosystem, but when the whole ecosystem follows it you get a gigantic ball of slightly different interpretations if the protocol, because something that is non-compliant but happens to work with some portion of the ecosystem won't get discovered u…

I don't think you can blame postel's law for people not following it.

> when the whole ecosystem follows it you get a gigantic ball of slightly different interpretations

You're describing the properties of a long-lived, well-used, well-supported, living system. We'd all like the ecosystems we have to interact with to be consistent and well-defined. But even more importantly, we'd like them to exist in the first place. Postel's law lets that happen.

If your app is a leaf node in the ecosystem, and it's simple enough that you have direct control over all the parts of your app (such that you can develop, test, and release updates to them on a unified plan/timeline), then, yes, fail-early pickiness helps, because the failures happen in development. Outside of that you end up with a brittle system where the first place you see many failures is in production.

Re: Handling cookies is a minefield

#262

Post by nghia999 »

jdlshore wrote: post #83
TheRealPomax wrote: post #52

Earlier quoted context omitted.

It sure doesn't, that was a comment for a completely different post. I have no idea why HN posted this comment on this article instead of the PHP 8.4 article I thought I was commenting on O_o

It’s happened enough that I suspect there’s a rarely-seen race condition somewhere in the Arc code that runs HN.

Hack 99999

Re: Handling cookies is a minefield

#263

Post by eru »

littlestymaar wrote: post #220
eru wrote: post #141

Earlier quoted context omitted.

> Sure you can't search for a name of a company or a project and expect it to be related to the company or project. But there's no way to solve that. There's a way to solve it partially: you can have a special part of your namespace tied to domains and require that eg com.google.some-package be signed by a certificate that can also sign some-package.google.com Of course, there's no guarantee that https://company.com…

That just makes package names harder to remember and type (and actually less secure as more prone to typosquatting and backdoors in seamingly harmless pull requests) for no benefit. Keep in mind that the majority of package by far don't come from companies in the first place, and requiring individual developers to have a domain of their own isn't particularly welcoming. It's going to be tons of complexity for zero ac…

> [...], and requiring individual developers to have a domain of their own isn't particularly welcoming.

Try reading my comment.

I specifically said that this shouldn't be required, and would only apply to one part of the namespace.

Re: Handling cookies is a minefield

#264

Post by 0x073 »

withinboredom wrote: post #259
0x073 wrote: post #246

Earlier quoted context omitted.

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.

I mean, anyone can open devtools and change the code to do whatever ... or install an extension that does it. So, since when can you guarantee that a browser client will actually do what you program it to do? In my experience, you can't guarantee anything on the client -- since forever. I was asking when/if that changed. I don't see why you would make that a personal attack?

But that a general problem, having a html only page with a form is the same problem. Only transfer what the user should see.

You need server verification for data that's important. Native programs can be changed with over programs or hex editor.

The talk was about data that is stored into cookies as json and csrf. (Cookies can be changed with devtools or extension)

Csrf is always an attack from third party against the user, if the user extract the data itself that's no csrf problem.

Because of this I thought you distrust js that can get attacked from third party, but yes js is as easy to change like .net or java programs.

Re: Handling cookies is a minefield

#265

Post by jamesfinlayson »

dgoldstein0 wrote: post #239
jamesfinlayson wrote: post #161

Earlier quoted context omitted.

I had the option to re-use the prod domain for non-prod a few years ago (the company's other two projects use the prod domain for all non-prod environments). I didn't really think about cookies back then but it just felt like a generally bad idea because disastrously messing up a URL in some config or related service would be much easier.

Nah dev should probably be a separate tld so the cookies are completely isolated. Stage, it depends - if you want stage to have production data with newer code, and are fine with the session / cookies being shared - host it on the same domain and switch whether users get stage or prod based on IP, who is logged in, and/or a cookie. That way your code doesn't have to do anything different for stage vs prod every time…

Yeah that's what I meant by separate domain - separate top level domain.

Not that we use cookies much but it's one less thing to worry about.

Re: Handling cookies is a minefield

#266

Post by rcxdude »

jmull wrote: post #261
rcxdude wrote: post #251

Earlier quoted context omitted.

Postel's law is the main reason why there are so many cases where something is being liberal in what it sends. It's a natural approach when trying to enter into an existing ecosystem, but when the whole ecosystem follows it you get a gigantic ball of slightly different interpretations if the protocol, because something that is non-compliant but happens to work with some portion of the ecosystem won't get discovered u…

I don't think you can blame postel's law for people not following it. > when the whole ecosystem follows it you get a gigantic ball of slightly different interpretations You're describing the properties of a long-lived, well-used, well-supported, living system. We'd all like the ecosystems we have to interact with to be consistent and well-defined. But even more importantly, we'd like them to exist in the first place…

I think you can blame Postel's law for being self-defeating. If the whole ecosystem is conservative in what it accepts, the whole ecosystem will be conservative in what it sends (because otherwise it won't be part of it). If the whole ecosystem is liberal in what it accepts (or just a significant part of it), some parts of it will be liberal in what it sends (because not everyone is going to rigidly follow the spec once they get something working well enough for the parts they test with), and that's where the problem comes from.

Re: Handling cookies is a minefield

#267

Post by ndusart »

marcosdumay wrote: post #258
ndusart wrote: post #247

Earlier quoted context omitted.

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

From wikipedia: > The principle is also known as Postel's law, after Jon Postel, who used the wording in an early specification of TCP.

From the mentioned specification:

> TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

Better to look in the sources ;)

Re: Handling cookies is a minefield

#268

Post by vbezhenar »

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.

Scripts can do almost everything, for example replace the whole page with login page identical to the real and send entered password somewhere. Leaking session identifier is bad, but it's not as severe compared to other things scripts can do.

Re: Handling cookies is a minefield

#269

Post by lknuth »

vbezhenar wrote: post #268
lknuth wrote: post #196

Earlier quoted context omitted.

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.

Scripts can do almost everything, for example replace the whole page with login page identical to the real and send entered password somewhere. Leaking session identifier is bad, but it's not as severe compared to other things scripts can do.

True, but your example is very targeted at a specific page. With local storage, you can have a simple short function that works everywhere and just sends everything back to your server. No need to specialize, works everywhere.

Re: Handling cookies is a minefield

#270

Post by paledot »

telgareith wrote: post #153
bpicolo wrote: post #148

Earlier quoted context omitted.

Server can store session state

Server side session state for more than authentication is way worse than "code smell." It requires a ping to a shared data source on every request. And, the same one for all of them. No sharding, No split domains... That gets expensive fast!

Wait, you can't shard on session ID?

And this is an ephemeral key-value store here, which is basically a best-case scenario from a performance standpoint. It's basically the last thing you're going to need to think about sharding, which is why session stores traditionally cohabitate(d) with web servers.

No, session storage doesn't get expensive fast. It's extraordinarily cheap unless you screw up the configuration very badly indeed (Apparently PHP still defaults to writing session data to disk?!)

Post reply on HN