[moot]

> 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.

[noir_lord]

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.

[jeffasinger]

Agreed.

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.

[tudborg]

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.