Looking for security trouble spots in Go code

Looking for security trouble spots in Go code(0xdabbad00.com)

45 points by leef 11 years ago | 4 comments

steakejjs 11 years ago |

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

programd 11 years ago | |

In case you missed it, people posting the incorrectly initialized session code to GitHub have inadvertently revealed their default session secrets.

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?

ekarulf 11 years ago | |

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

steakejjs 11 years ago | | |

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

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