Updated April 17th... I'm no longer upset (with myself) and now see this as too "ranty". But I will leave it as is because a few points are valid. And I have added some stuff...
Before I go into detail about how I fucked something up in THIS code, I want to say this:
Consider informing others about stupid code (or bad, insecure, faulty, dumb, whatever) your duty.
It may be that I am just too mad at myself for allowing stupid shit in my code, but I feel that "the community" needs to openly discuss poorly implemented code.
We were recently contacted by someone from the Open Security Foundation questioning us whether a change log "fix" reference was security related — it was not. Which is cool, we thought. People "out here" are concerned about Internet security.
You see, we spent days searching their site — and other security minded websites — and found many well documented "vulnerabilities", which would indicate that the security folks are doing their job.
Because, in all the days of our searching, we found very little discussion of how to implement secure code. We found, "Update to the latest patches" as pretty much the answer to everything.
There are databases of "documented vulnerabilities" but a dearth of discussions of general secure programming practices.
We found several discussions of SQL Injection, and PHP's documentation on security is really good, but we found little else. Many code examples "out here" are by nature just enough to get the idea across of how to implement something. But that can be a problem if most people (like me when I started programming) just "copy and paste" those examples. Handling GET and POST data poorly is the source of — what? — 90% of all security problems on websites.
But we find little discussion of that.
Security fellows seem to just want to talk among themselves and create WAFs.
Maybe I'm wrong. I don't know. I'm not on any security mailing lists where I assume most security issues are discussed.
Now that I've calmed down, I'll explain what happened. First, there was nothing wrong this code (in this incident that I am writing about). We are, as we mentioned, adapting THIS as an API, and it was some secondary code installed elsewhere that had the problem.
What got me upset was that we made a change to THIS which was a move away from an INI file for banning commenters (via things like IP address) to a SQL database — and we released too early and did not finish the interface...
And when that comment spammer was detected we had no quick way to block it. And that pissed me off.
We've encountered comment spammers before, of course, and since they only want to post findable links we simply do not allow HTML in comments. In addition, we search for the BBCode strings
[link= and block those attempts — we were thinking of even permanently denying by IP those who do use those string.
Anyway, based on a few other websites we had involvement with, we noticed that spammers are, I used this description before, like pigs sniffing for food, and if it's not food — can't post links — they move on.
This comment spammer that found our "food" was very pig-like and kept at it, and at it, using multiple IP addresses. But we did find one little thing that was common enough to all of them to block them. (And of course we fixed the error that let the HTML through.)
That was two days ago.
The interesting thing with this little piggy was that he stopped posting after a while, but the page was being read constantly since the spammer hit — even today the page is being searched for from multiple IP address, and all have that common piece of data so all their attempts are being issued 404s.
And yet still they come. It was as if a bot posted a bunch of shit — all porno links — and called on all his friend-bots to read those links. It's really fucking weird.
1. We subsequently did find a security problem but it was unrelated.