5 ms·

Not requiring explicit parameters for things like domain, etc in this day and age is just ridiculous. I expect PHP5 to be that way. php7 and golang doing that,

by gcb0 8y ago

Not requiring explicit parameters for things like domain, etc in this day and age is just ridiculous. I expect PHP5 to be that way. php7 and golang doing that, in this day and age, is inadmissible. Yeah you should still be able to write a quick hack and make it work fine without worrying about security, but the language/framework should at least make you explicitly say "set this cookie, and allow all domains and client side access. fine".

paulddraper 8y ago
FWIW, that's exactly how it works in client-side browsers scripting. document.cookie = 'name=value';
- gcb0 8y ago
  client side cookoes are already inherently unsafe. on the server, the chance that your cookie is for auth is high, so make a secure cookie the defaul. force http headers that say server only, etc. Then allow for the security to be dropped via the extra arguments, not the other way around.
jrockway 8y ago
I'd personally prefer that the low-level core library just handle encoding and decoding. Any rules you want to add on top of that, just add on top of that.
jorams 8y ago
> Not requiring explicit parameters for things like domain, etc in this day and age is just ridiculous. While I agree with the sentiment, domain is probably the worst possible example, because it defaults to the most specific possible configuration of "exactly the same domain".
- elithrar 8y ago
  Correct; the same goes for Path, which is often a fun bug for many newer web programmers when they set the cookie on '/login' and then wonder why the cookie isn't being passed on '/store' or even '/'.
elithrar 8y ago
On this topic, and as a co-maintainer (but not original author) of gorilla/securecookie, which is mentioned in this article: - Setting Secure and HttpOnly attributes are exactly what I do by default in gorilla/csrf - you have to explicitly override these[1] - CSRF prevention without these is a losing battle. I'm positive many devs miss the docs though, wonder why the library isn't working on their local machine (without HTTPS), and move on to a library that doesn't have these safe defaults. This is a hard thing to fix: docs only go so far. - securecookie just returns the authenticated, and optionally encrypted, cookie value. It's pretty minimal. I'm already looking at a v2 with some breaking API changes[2], including using an AEAD instead of the original authors' AES+CBC + HMAC construct. This could also be an opportunity to provide a convenience method - WriteCookie - that sets sane defaults for you, ala gorilla/csrf (which I wrote from scratch) But as per the other comment: "all domains" is not correct. Cookies are still origin-scoped. HttpOnly is the real problem; followed by Secure. The SameSite attribute[3] is another lever to pull here: and, of course, for devs to learn & potentially disable. [1]: https://godoc.org/github.com/gorilla/csrf#Secure https://godoc.org/github.com/gorilla/csrf#Secure [2]: https://github.com/gorilla/securecookie/issues/43 https://github.com/gorilla/securecookie/issues/43 [3]: https://github.com/gorilla/sessions/releases/tag/v1.1.2 https://github.com/gorilla/sessions/releases/tag/v1.1.2

by gcb0 8y ago

paulddraper 8y ago

FWIW, that's exactly how it works in client-side browsers scripting. document.cookie = 'name=value';

gcb0 8y ago
client side cookoes are already inherently unsafe. on the server, the chance that your cookie is for auth is high, so make a secure cookie the defaul. force http headers that say server only, etc. Then allow for the security to be dropped via the extra arguments, not the other way around.

jrockway 8y ago

I'd personally prefer that the low-level core library just handle encoding and decoding. Any rules you want to add on top of that, just add on top of that.

jorams 8y ago

> Not requiring explicit parameters for things like domain, etc in this day and age is just ridiculous. While I agree with the sentiment, domain is probably the worst possible example, because it defaults to the most specific possible configuration of "exactly the same domain".

elithrar 8y ago
Correct; the same goes for Path, which is often a fun bug for many newer web programmers when they set the cookie on '/login' and then wonder why the cookie isn't being passed on '/store' or even '/'.

elithrar 8y ago

On this topic, and as a co-maintainer (but not original author) of gorilla/securecookie, which is mentioned in this article: - Setting Secure and HttpOnly attributes are exactly what I do by default in gorilla/csrf - you have to explicitly override these[1] - CSRF prevention without these is a losing battle. I'm positive many devs miss the docs though, wonder why the library isn't working on their local machine (without HTTPS), and move on to a library that doesn't have these safe defaults. This is a hard thing to fix: docs only go so far. - securecookie just returns the authenticated, and optionally encrypted, cookie value. It's pretty minimal. I'm already looking at a v2 with some breaking API changes[2], including using an AEAD instead of the original authors' AES+CBC + HMAC construct. This could also be an opportunity to provide a convenience method - WriteCookie - that sets sane defaults for you, ala gorilla/csrf (which I wrote from scratch) But as per the other comment: "all domains" is not correct. Cookies are still origin-scoped. HttpOnly is the real problem; followed by Secure. The SameSite attribute[3] is another lever to pull here: and, of course, for devs to learn & potentially disable. [1]: https://godoc.org/github.com/gorilla/csrf#Secure https://godoc.org/github.com/gorilla/csrf#Secure [2]: https://github.com/gorilla/securecookie/issues/43 https://github.com/gorilla/securecookie/issues/43 [3]: https://github.com/gorilla/sessions/releases/tag/v1.1.2 https://github.com/gorilla/sessions/releases/tag/v1.1.2