The first way I did it was just read the file, parse the json, check for nulls, and print. Then I piped this to a file. That is too boring though.
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.
What if you are an experienced engineer talking to another experienced engineer ?
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
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.
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?
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.
Google has a big fuzz-farm and Project Zero looking for this type of thing and even they did not find Heartbleed years ago. They are nabbing tons of bugs but there are many that are simply buried.
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.
No. A fuzzer abstracts away some of the need for intricate, function by function analysis, but you really want to know what the source code is doing to be successful.
Fuzzing "blind" will work...but you will miss a lot without more instrumentation than that.
The new stuff happening in the PHP space is really really awesome.
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.
No. SSL stripping is an attack where you prevent a user from upgrading to an HTTPS connection. That isn't possible here.
Many sites have multiple tiers of authentication. For example viewing items to purchase is over HTTP but to actually checkout or manage your account requires you to go to HTTPS and reauthenticate on an HTTPS login page. Always. After this you are kept on HTTPS for the trusted actions. Amazon only does shopping over http but trusted actions are all HTTPS.
This has been amazons authentication scheme for years and it is actually the same as googles (where Google does have http assets, they force a reauth before going to https only stuff).
The most an attacker could do is inject code on http pages, annoyingly add things to cart, purchase items with 1 click purchase (inject javascript that clicks the button) and eavesdrop on all items purchased (quite serious).
BUT they cannot perform SSL stripping if Amazon doesn't do any auth over HTTP. An attacker could do some phishing like attacks to try to convince the user to put their password in at the wrong time, though.
An attacker can also replace an https:// login URL with an http:// one on a page sent via unencrypted connection. The http:// page can then be manipulated in any way.
Right, but you get a redirect to the https login page with an http login URL.
An attacker can attempt phishing with HTML/JS injection on a HTTP page but an attacker cannot get a user to be looking at Amazon's real login page over http.
I think the problem here is the term ``SSL stripping'' was used and it may be kind unclear what MITM attacks is actually encompassed by it.
The OP wrote ``An attacker can easily steal passwords with SSL Stripping''. If OP meant he can easily steal passwords by basically a s/https/http on all urls on the page, OP's wrong. The attacker needs to create their own fake login page, present it to the victim, and hope the victim falls for it
Once the attacker hijacks the plaintext HTTP connection, she can pretty much do whatever she wants with the user. Of course, that's provided we're talking about a casual user, who isn't going to pay much attention to the HTTPS indicators.
Thus, the first leg of the traffic, between the victim and the MITM attacker is forever unencrypted. The second leg, between the attacker and the servers can be encrypted; it's not going to impact the attacker's capabilities in any way.
The attacker doesn't need to create their own fake login page, etc, because she can simply proxy all traffic from and to Amazon's servers.
Not all traffic. Amazon has a separate SecureOnly cookie for access to their trusted pages that isn't sent over HTTP. Without that cookie not all traffic can be proxied.
If Amazon has any secure cookies, they're not going to affect this particular attack. The traffic leg between the attacker and Amazon's servers can be encrypted, which means that she will receive the secure cookies. Because the leg between the victim and the attacker is not encrypted, the attacker simply rewrites the cookies to remove the "secure" flag. Thus, from the perspective of the victim the cookies are not secure.
To summarise, the attacker injects herself into the traffic stream, fully controlling the Amazon side of the communication, and forwards traffic to the victim rewriting as appropriate. The account compromise occurs when Amazon asks the victim for the password (as they do before each purchase) and the attacker captures the password (because it will have been sent to her, rather to Amazon).
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.
All the MITM has to do is relay the traffic to the correct secure location, passing the credentials passed via the compromised HTTP connection, and the user's entire account is compromised.
Remember: HTTPS does not ensure the identity of the client.
Relay what credentials from the HTTP connection ? There are none...
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.
User browses Amazon normally, MITM proxy simply alters response links containing "https" back to http, keeping track of what links were downgraded so it can start relaying between http and https when one of those links is hit.
User requests login page over http
HTTP request is intercepted, and relayed over https to amazon
https response from Amazon is modified to show http links, and presented back to the user
User fills in credentials and submits request over http
Request is intercepted, and relayed over https back to Amazon
MITM now has all credentials.
Doesn't require any special tools, or a phishing page, just a spot between Amazon and the user, and the ability to re-write responses from https back to http.
HTTPS with a HSTS setting would mitigate this, since the browser would refuse to request the HTTP page if the user had ever successfully visited https://www.amazon.com before.
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