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

111–120 of 270 posts

Re: Handling cookies is a minefield

#111

Post by draw_down »

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…

Yeah, isn’t that how you represent a list of values? (Or maybe better to say a collection, not sure if ordering is preserved)

Re: Handling cookies is a minefield

#112

Post by Dilettante_ »

qingcharles wrote: post #110
mardef wrote: post #97

Earlier quoted context omitted.

Just want to point out that location names are used for codenames because they cannot be trademarked Big tech uses them instead of wasting legal time and money having to clear a new name that's temporary or non-public. Changing the name to Tokio removes this benefit and still leaves it disconnected from its purpose.

The name of the city is 東京 -- anything in Latin characters is a rough transliteration. Tokio was the common spelling in European texts until some time last century, and is still used regularly in continental Europe. see also, e.g. Tokio Hotel

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

Re: Handling cookies is a minefield

#113

Post by h4ck_th3_pl4n3t »

flotwig wrote: post #23
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.

It's funny that you mention NewCookie, there is actually a deprecated Set-Cookie2 header already: https://stackoverflow.com/q/9462180/3474615

Imagine pwning a frontend server or proxy, spawning an http/s server on another port, and being able to intercept all cookies and sessions of all users, even when you couldn't pwn the (fortified) database.

This could have a huge advantage, because if you leave the original service untouched on port 80/443, there is no alert popping up on the defending blueteam side.

This gives me an idea for a project...

Re: Handling cookies is a minefield

#115

Post by [deleted] »

Analemma_ wrote: post #105
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,…

This is also the fault of shit-tastic middleware boxes which block any protocol they don't understand-- because, hey, it's "more secure" to default-fail, right?-- so every new type of application traffic until the end of time has to be tunneled over HTTP if it wants to work over the real Internet.

[deleted]

Re: Handling cookies is a minefield

#116

Post by kangalioo »

anamexis wrote: post #44
pimlottc wrote: post #33

Earlier quoted context omitted.

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 )

That is true, but in that case they are part of the value itself, they're not doing anything special: > Per the grammar above, the cookie-value MAY be wrapped in DQUOTE characters. Note that in this case, the initial and trailing DQUOTE characters are not stripped. They are part of the cookie-value, and will be included in Cookie header fields sent to the server.

Why does the specification specifically mention them, then?

Re: Handling cookies is a minefield

#117

Post by jmull »

klysm wrote: post #40
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?

Well, we’re getting into how to choose metaphors here. Not being literal, there’s always room to stretch. Still, you try to choose a metaphor with characteristics congruent with the topic.

With a minefield, you can be doing something perfectly reasonable, with eyes open and even paying attention yet nevertheless it can blow up on you.

Here, though, there’s no special peril. If you just follow the standard everything will be fine.

If this is a minefield, then practically everything in software development is equally a minefield and the metaphor loses its power.

(Later in the article they touch on something that is a minefield — updating dependencies. There’s probably a good article about that to be written.)

Re: Handling cookies is a minefield

#118

Post by anamexis »

kangalioo wrote: post #116
anamexis wrote: post #44

Earlier quoted context omitted.

That is true, but in that case they are part of the value itself, they're not doing anything special: > Per the grammar above, the cookie-value MAY be wrapped in DQUOTE characters. Note that in this case, the initial and trailing DQUOTE characters are not stripped. They are part of the cookie-value, and will be included in Cookie header fields sent to the server.

Why does the specification specifically mention them, then?

To clarify that by the spec, double quotes are allowed in the cookie value, but only at the beginning and end.

As for why that is, I have no idea.

Re: Handling cookies is a minefield

#119

Post by kevincox »

draw_down wrote: post #111
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…

Yeah, isn’t that how you represent a list of values? (Or maybe better to say a collection, not sure if ordering is preserved)

But if the attributes are exactly the same then the cookies replace each other. So this isn't a general mechanism for representing a list.

Not to mention that the way to delete a cookie is sending a replacement cookie that expires in the past. How are you supposed to delete the right cookie here?

Re: Handling cookies is a minefield

#120

Post by echelon »

Dilettante_ wrote: post #112
qingcharles wrote: post #110

Earlier quoted context omitted.

The name of the city is 東京 -- anything in Latin characters is a rough transliteration. Tokio was the common spelling in European texts until some time last century, and is still used regularly in continental Europe. see also, e.g. Tokio Hotel

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.

Post reply on HN