Having been through open sourcing an app platform repo (<a href="https://github.com/documentcloud/documentcloud" rel="nofollow">https://github.com/documentcloud/documentcloud</a> ) that wasn't explicitly created w/ open sourcing in mind, moot has my deepest sympathies.<p>Moot left out the most sensible response to Mistake #5:<p>I went through a rushed 8hr rebase to remove all of our keys, certificates, cookie secrets and the like before DocumentCloud's platform was opened. Two days after, a friend asked me why I hadn't simply revoked and replaced all of our secrets to the sound of me facepalming repeatedly.<p>It is always much easier just to revoke and replace your secrets. Doing so should always be relatively easy for you to execute, and having a chance to practice that is also always good.
Of related interest to HNers: Admin consoles getting owned up is a fairly frequent way that even security-conscious shops lose their web apps / databases / networks, because one often does not code defensively against malicious actions executed by "trusted" users. You can mitigate this quite a bit by putting them on a private network interface and requiring the admins VPN in to use them.
> "Mistake #3: Unescaped SQL query..."<p>This should be "failure to use parameterised queries." The term 'unescaped' may lead some to think that simply escaping characters is sufficient.
The disclosure of these mistakes is both kind of relieving, in that the errors were obvious in <i>nature</i>, and terrifying, in that even though they seem "basic", they were still committed by a dev as experienced as moot. This would be a good post to create a checklist from, if nothing else.<p>I wonder how old the code was for "Mistake 2"? SQL injection is something most sites have patterns/frameworks to prevent, but unless the site started out with such practices...the code that was written when the site was just a fun side-project might go unchecked even as the site becomes a well-run project in its later years.
Thanks for this Moot, I love the fact that people are being more and more open with how they were hacked. These post-mortems help others identify areas where they may be vulnerable which in turn helps the community as a whole.<p>Sorry about you getting hacked twice in one day though. I hope things have been better since then!
I'm not familiar with DrawQuest, but why not sell it "as is" instead of shutting it down completely? Especially when you have 100k monthly actives?
Security is a usability nightmare. All the instinctive and usually lazy things people do are just bombs waiting to explode. I don't know why this continues to be the case. Most platforms for web development should have taint checking turned on to the highest setting by default. SQL access points should scream in your face every time you use a bare query. With a bit more you could even get developers to do the right thing in terms of salts, passwords, and hashes. I think it is clear that pointing people to OWASP and asking them to read their security articles before bedtime is not as useful as it could be. Library writers also need to be involved and use safe options by default instead of opt-in.
The list of vulnerabilities in 4chan read like a standard web hack CTF. I'm surprised a site as big as 4chan has multiple OWASP top 10 issues, especially after the source was leaked. Storing credentials in client side cookies? Who wrote that shit?
Nobody mentioned the fact that _you don't put secrets in a versioning system_. .gitignore the configuration files and have example files available, or use configuration files that can import the missing parts (the secrets) from an ignored file.
Another way is to put the secrets in environment variables outside the project.
In any way, if they're missing provide a meaningful message to the developer.
I do understand that you must keep some of these secrets available somewhere: just don't version them.
Some security bad practices, but it happens to the best of us. Glad you got that figured out though.<p>I always tell my devs on the first day, "leaving AWS keys in a public repository is as bad as showing up drunk to work". Mainly because the last guy to leave our AWS keys in the open was drunk at work.
This makes me wonder what kind of practice change would be best to help avoid this sort of thing. Maybe anytime you put in something that you know is hacky and insecure as a one-off, you should put a note in wherever you would look regularly, and maybe some kind of reminder too, to make sure that your one-off is either removed or properly secured reasonably quickly.<p>Or maybe just a rant on PHP and/or frameworks that make it easy to do the wrong thing, and hard or time-consuming to do the right thing.
I actually think this is something GitHub should help with. When you flip a repo from private to public, it should prompt you asking if you want to wipe out all the version history first.(essentially create a brand new repo in the background)<p>Seems like far too common a mistake and something they could help fix once and for all.
So Mistake #4 is something you hear over and over again is bad but I don't understand why it's so bad. If you have the password you can just login anyway and I don't see how it affected this particular case either. Please enlighten me.
moot, why do you refuse to speak to us on 4chan while go happy hand-in-hand with all these web 3.5 cloud entrepreneurs here? Want to find some investor friends? Thanks for ignoring your actual friends.
> Boneheaded cookie auth—we simply stored the bcrypted password from the database in a cookie, which was all that was required to pass PHP auth.<p>Wh... Why... Who...<p>How was that ever OK?