The big take-aways from my talk. Go doesn't have a lot of unsafe functions.
HTMLTemplates package and exec package are very resistant to common web attacks, so much so that I had trouble writing vulnerable code to XSS and RCE
As for the tool that attacks Gorilla Sessions, I found a lot of people on github who were not initializing their session securely. Most people in the first 30 pages of github search were doing it wrong. This is most likely a pretty widespread issue. It seems they didn't realize this was an AES key...The blog post is not completely correct saying it will be used for an HMAC. It will...but it is also used as an AES key.
The G2B2 source has a list of the 40 "secret" session encoding strings steakejjs managed to find. He uses it to shortcut the decoding process. My favorites have to be "", and the ever popular "secret123". This is a security failure of similar type, though not severity, as embedding your AWS credentials in code on GitHub.
The developer is the weakest link in this case, but I have to wonder if the API design of Gorilla Sessions does not bear part of the blame. Should you even allow the developer to not correctly encrypt their sessions by default?
In order to encrypt the values in the session, rather than just encode you have to do a NewCookieStore([]byte("HMACKey"), []byte("CipherKey")) instead of a NewCookieStore([]byte("HMACKey")). I guess to answer your question, separate keys.
https://gist.github.com/steakejjs/6c17f07c4ca72115bfec
Here's a gist that shows a regular session, created with NewSessionStore([]byte("something-very-secret")) having the value's inside recovered easily.
The strings "foo" and "bar" are pretty easy to spot in the base64 output
