

Looking for security trouble spots in Go code - leef
http://0xdabbad00.com/2015/04/12/looking_for_security_trouble_spots_in_go_code/

======
steakejjs
I actually wrote a tool[0] to attack gorilla sessions that are mentioned at
the bottom of this, and gave a talk on some security functions in Go.

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.

[0] [https://github.com/steakejjs/G2B2](https://github.com/steakejjs/G2B2)

~~~
ekarulf
Is it used to derive separate HMAC and AES keys or is the same key used in
both contexts?

~~~
steakejjs
After reviewing the code it looks like I was wrong. The code from the tutorial
won't provide any encryption for your sessions, only integrity.

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](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

