It's worthwhile remembering, (if you have any more problems), to check your own security, setup and coding before laying blame on someone elses.

I did ;-) In fact, I spent almost two days checking out various things. The thing is, the other copy was on another domain which is otherwise inactive and has separate logs. Not exactly the kind of place you think of checking out. I wish I had had access to some kind of DB log.

But I know what you mean... I often waste lots of time investigating crazy theories (eg. your software only works while I'm not sitting on my chair) only to find out a user messed up something basic (eg. I forgot to mention I'm using linux-fedora-pre-alpha-bleeding-edge on a mac laptop). It seems that's just the way it is with software development.

Given the mad stuff I implemented to work around this problem, I'm pretty sure we'll be spam-free for a long time. But I'll know where to look if it ever becomes a problem again.

Funny you should mention this just now, I found out that was indeed the case late friday night. The web site was tested on another domain before being deployed and apparently it was not correctly removed: access to the site itself was denied but a direct link to the forum still worked. That would explain why the spam seemed to just drop into the DB and there were no traces of anything in the server logs.

It's worthwhile remembering, (if you have any more problems), to check your own security, setup and coding before laying blame on someone elses.

zap: Could this (another copy of PunBB using the same database settings but with different pun_config options) be the issue for you?

Funny you should mention this just now, I found out that was indeed the case late friday night. The web site was tested on another domain before being deployed and apparently it was not correctly removed: access to the site itself was denied but a direct link to the forum still worked. That would explain why the spam seemed to just drop into the DB and there were no traces of anything in the server logs.

I'm pretty sure the forum will be spam-free now. I'm sorry about everyone's wasted time. I'll now go and kick someone for leaving junk on a web server which wasted several hours of my time as well.

Are you sure nobody just got hold of your DB info? It certainly seems more plausible.

Seems unlikely. The spam is pretty obviously automated and I doubt someone could grab the information of enough forum databases to make that worthwhile. Unless there's another common hole somewhere which allows that part to be automated... but it all seems farfetched.

Besides, I'm not even sure outside access to the DB is possible with only the DB login. I don't see why it would need to be. So they'd have to have some kind of access to the web server as well... at which point I'd expect problems greater than plain old spam The rest of our website, some of which is also in the DB, is quite intact and spam-free.

I guess my point is that SQL injections are not bugs that should be fixed but something that should be designed out of the system, relying as little as possible on the developer being fully awake when he writes the code. :-)

That is incorrect. Anyone who writes any code whatsoever, in any language, should design it as securely as possible regardless of (the|any) underlying security. And with regards to semantics, php is not perl. Perl is not shell. Shell is not (C|C+|C++). They all vary in their abilities and semantics. One should never, and I do mean never, assume any level of security so that they can relax their own coding methods. As a software developer, you should have been taught that before you were ever even allowed near a keyboard.

Unfortunately, that's the way it has to be done to support anyone using the mysql extension (as opposed to mysqli) and (I think) the SQLite extension. Prepared statements, stored procedures, etc aren't features that everyone with a PHP install supports, so this is the way it has to be done.
I would disagree with your overall assessment though. User input is properly sanitized (using $db->escape or intval, depending on the type of data) before being put into the query. We're not just accepting any input from $_GET and shoving it into the query.
If you have a suggestion for another way to construct queries, I'd be interested to hear it.

Aww, I didn't know SQL was in such a crappy state still in 2007.

As for another way, wouldn't it be possible to factor all db access into a single function where a query format string (say, something printf-like but less messy) would merged with the query arguments into a final SQL query? The idea is to have a single location where the arguments are escaped so none can be forgotten. It might also make the queries easier to read. Again, I don't do much php (mostly know how it works from perl) so maybe this makes no sense.

As it is now, there are three ways parameters can be handled: $db->escape when building the query, intval which seems to often be applied a little earlier and script-generated values which are never escaped at all. This makes it easy to mix things up and forget an escape.

I guess my point is that SQL injections are not bugs that should be fixed but something that should be designed out of the system, relying as little as possible on the developer being fully awake when he writes the code. :-)

Yes, I upgraded when the spam started coming in but it didn't make a noticeable difference. I checked the IPs but found zero references to them. Unfortunately I've deleted all the spam users since so I can't check again. I even tried to roughly scan the log by date/time for suspicious stuff but couldn't see anything fishy. I'll try to find some time to look again since there was a new spam episode a few days ago (it had been quiet for a week or two). There are no mods that I know of on the forum, it's a plain install with a few stylesheets changed to make it fit in our website.

Sure, drop me an email and I'll point you there.

You're welcome :-) And thanks for actually caring about the issue.

StevenBullen wrote:

Idiot!

Smartys.... fair play for even replying to him. He dont deserve it... 10/1 he is under 15.

And you are obvisouly far, far older to have so much wisdom.

FWIW, I'm well into my 20s and a software developer. Smartys at least knows how to deal with criticism.

Enough wisdom that I understand how to ask a question instead of going on a rant mission...

20s and a software developer.... damn... shame that your age and job don?t teach you how to post a problem.
EDIT: criticism.... I don?t care about the criticism... it?s your attitude mate!!!

Do you honestly not see what I am getting at here?

For one thing, there's SQL sprinkled all over the place in the php scripts without systematic (AFAICS) protection against injection. SQL queries built on the fly with user input screams "it's the 90s and security isn't an issue yet". Maybe there's something I don't see (SQL/php isn't really my domain) but it sure doesn't look solid.

Unfortunately, that's the way it has to be done to support anyone using the mysql extension (as opposed to mysqli) and (I think) the SQLite extension. Prepared statements, stored procedures, etc aren't features that everyone with a PHP install supports, so this is the way it has to be done.
I would disagree with your overall assessment though. User input is properly sanitized (using $db->escape or intval, depending on the type of data) before being put into the query. We're not just accepting any input from $_GET and shoving it into the query.
If you have a suggestion for another way to construct queries, I'd be interested to hear it.

Are you running the latest version (1.2.15)? Have you actually checked the IPs against entries in the access_log? What mods are you using on your forum?
Could you provide a link to your forum? I'd like to investigate this a bit myself.

Before I forget to say it, zap, thank you for clarifying your post

Idiot!

Smartys.... fair play for even replying to him. He dont deserve it... 10/1 he is under 15.

And you are obvisouly far, far older to have so much wisdom.

FWIW, I'm well into my 20s and a software developer. Smartys at least knows how to deal with criticism.