The disclosure of these mistakes is both kind of relieving, in that the errors were obvious in nature, 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.
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.
> they were still committed by a dev as experienced as moot
I'm not a terribly good programmer, and have been very hands-off with 4chan's code for quite some time. I still direct development and am responsible for the servers/sysadmin tasks, but there are far more talented developers out there than I. In the case of Canvas/DrawQuest, I was 100% uninvolved on the tech side.
But again, in both cases I accept full responsibility for the breaches since ultimately it's up to the project leader to ensure these things don't happen -- even if not active on the technical side.
> I wonder how old the code was for "Mistake 2"?
Very new. It was in a once-off file that we used to quickly pull stats about reported posts, which a) shouldn't have been on a domain without HTTP auth, b) should have been deleted long ago, c) shouldn't have had a bugged auth check or injection vuln to begin with.
one-off files have a habit of hanging around and temporary often becomes permanent.
This isn't to say that you should treat all one-off's and temporary solutions as permanenent but it is a good idea to audit them periodically.
Storing that kind of metadata about code is something I've often pondered we could do better, putting it in comments is a nasty hack, storing it away from the code means it instantly gets out of date, commit messages are not a good place to put that stuff either.
I've never come up with an elegant solution even in my head but it would be something I'd love to have for my own uses.
Someone once came into my office and asked why the email export feature had stopped working. Once they described going to test.php, I realized that about a month ago, I had migrated our version control system to a new deployment system, and hadn't included test.php, what I thought to be an insecure relic left hanging around by a predecessor.
Things that end up on a live web server are one offs much less than the people who make them think.
Codebase I once worked on, I found a /csv route that dropped the entire customer database in CSV format and /route_csv that enumerated all the routes the application had including admin and cron routes :| (denial of service by spamming the cron routes that did no access checking was the least of it).
When I checked the commit date it was 19 months ago..and in production for 17 months :|
The midden and the windmill fully hit each other that day.
How do you query your database?
There is still a bunch of new PHP projects that use mysqli::query, which is like playing with fire compared to using PDO::prepare
If you are still using mysqli, changing to PDO for future commits might help reduce chance of creating these kind of vulnerabilities.
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.