steakejjs
Joined 12 years ago
Joined 12 years ago
The work he has been doing with AFL and googles big fuzz farm, focusing on utilities that are used daily without thought is insanely important, imho
The next way I did it was with Vim replaces. There might be sexier ways of doing this?
1) A big replace to get rid of all the junk.
%s/\%Vemail.*creditcard/creditcard/g
2) A big replace to fix nulls in the credit card %s/\%V.*creditcard.*null.*//g
Then I could either change my code to not check for nulls or keep cleaning up this data until I have a CSV.This Vim flow is the exact thing I do every week or two at work when building the Chrome HSTS preload list into our product. Anyone know the sexier ways to make this really really fun?
I should note to those not super familiar with vim that may try this, my vim commands are over a visual block (the json string), since this was in the same file as my code.
Seems to me if someone writes bad code when they SHOULD be writing good code, code-shaming might be in order.
I'm all for being nice and understanding. Everyone programs at a different level and I may not write code that is as good as I think, but some code is just obviously bad...and constructive criticism (if willing to be accepted) might help
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
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.
Brushing up on:
K&R - The C Programming Language
K&P - The Unix Programming Environment
K&P - The Practice of Programming
Kerrisk - The Linux Programming Interface (Not light reading)
Even though it is mostly review, reading code and seeing commands that K&R&P run has actually helped my workflow, code quality, etc.
Highly recommend re-reading if it has been a while. Even things like variable names have noticeably improved since beginning re-reading.
And, the Linux Programming Interface....is huge. There's always more to learn in there.
This seems to me a bit like when you do a maze starting from the finish and it is, for whatever reason, trivial to go from one end to the other.
It is neat that it is 2015 and fuzzers are cool again, though.
HHVM + HACK + XHP is an entirely different experience compared to writing PHP. Code can actually be very clean and lots of bugs can be found that may have previously gone unnoticed + performance benefits.
Just wanted to say FB is doing an exceptional job with these projects.
I never said an attacker can't do this. I'm saying an attacker can't do a s/https/http and have a user end up at an HTTP login page, where the attacker can sniff credentials.
It sounds like you are talking about creating a phishing page and injecting it, hoping the user enters their credentials, and stealing them. I already said this was possible.
[ my public key: https://keybase.io/ej; my proof: https://keybase.io/ej/sigs/C3HkPc4k5SISC7AK-sWYBiQ6q08dOW-MVrdoWl16x_4 ]