A fix is unlikely—I raised an issue on this over a year ago and my recommendations were rebutted: https://github.com/astaxie/build-web-application-with-golang...

Web apps/services should use gorilla/sessions[1], securecookie[2], and Go's bcrypt/scrypt libs.

[1]: http://www.gorillatoolkit.org/pkg/sessions [2]: http://www.gorillatoolkit.org/pkg/securecookie

> A fix is unlikely—I raised an issue on this over a year ago and my recommendations were rebutted: https://github.com/astaxie/build-web-application-with-golang....

That is incredibly unfortunate especially since much of the guide seems pretty decent.

I disagree—the guide is Beego centric, and Beego does some peculiar things[1]. I feel like I'm ragging on someone's hard work here, but I take web security seriously, and I want to make sure frameworks (which are attractive to newbies) are doing sane things.

[1]: https://github.com/astaxie/beego/issues/620

Really impressed by your patience and the thoroughness of your answers. Although the outcome is disappointing, you did an excellent job communicating not only what should change, but why and with references.

As a cyber security professional, that was an extremely disturbing read.

meanwhile I started to write my own little book on webapps with Go: https://github.com/thewhitetulip/web-dev-golang-anti-textboo...

Which also teaches horrible security practices. Pleas also use gorilla/csrf and not your own brown "solution".

okay, you could be less insulting though

Interesting. Not sure why you'd keep them intact.

What's the hip solution for keeping a session-scoped, server-side data store? Recently dove into that for Hapi.js, found out that many people encrypt these and stuff them into cookies, ASP style - with all the same patterns of fail.

Also - the developers claim this is a feature (after all, you don't have to worry about load balancing or distributing your state information on the backend. sigh )

gorilla/sessions (for which I became a maintainer last year) has Redis/BoltDB/Postgres/etc. backends: the cookie stores an opaque ID, and all the data is in the server side store (allowing you forced expiration, etc).

Cookies are also supported, and everything is HMAC'ed at a minimum. You can optionally encrypt, but since you should only be transmitting over TLS, doing so can be redundant.

I wonder how long it'll take before we get usable TLS-based sessions again. AFIK the only way to do that now, is via client certificates, and the UI for that (on the browser end) is still so bad it's practically unusable.

I think it's perfectly valid (in an imperfect world) to use a (secure) cookie as a session token a la kerberos over http(s) -- and with authenticated encryption wrapped around the cookie I don't see much problem "storing" some session state in there (opaque to the user agent/user).

Still somewhat unclear what that actually buys you in terms of scalability/simplicity -- all communication should be over TLS anyway, which means there will be a session context between the user agent and the TLS terminating server/load balancer (or if you have none, between the ua and the web server).

I suppose it allows you to separate the user session from the TLS session -- which might be "fine" from a system level view, but I don't think it's really a security "win".

Anyway, I'm happy people like you take the time to maintain stuff like gorilla/sessions -- it's part of what makes modern languages/frameworks so easy to use to get stuff done (and get them done in a sane way...).

Very cool, I'll have to take a look at the gorilla/sessions work.

As for the cookie mode, I'd make encrypt + HMAC [along with the nonce + timestamping & expire goodies] the default. There are a lot of reasons you shouldn't show a user what's in their 'internal state' - and users of your library may not understand that.

If you're HMAC'n you're already using a secret key, so - no great shakes to default to the encrypted mode.

thank you for your hard work!