IMPORTANT: Words to avoid in Thread Titles

[Basil]

In order to harden the BCF server from possible hacker attacks, I have installed a set of a few hundred different "security rules" which prevent potential hackers from accessing the site or from issuing commands via their browser that could damage the forum.

99% of the time, these security rules don't interfere with legitimate users, however, every once in a while, one of the rules may cause problems for legitimate forum members.

One such rule was recently discovered to cause problems when a member was prevented from accessing a thread that had a specific word in the thread title. When you would try to go to that thread, one of the many security rules installed on the server would see the word "update" in the thread title, which of course puts that word in the browser address bar. This security rule is meant to prevent hackers from issuing a database "update" command to alter the contents of our database ("update" happens to be an SQL database command used to modify a database). The security rules, not wanting to allow a possible database injection attack, prevents your browser from accessing the server with that word in the browser address bar (thus you will get a "forbidden" error).

So as not to have to disable that security rule, I have done a mass update of thread titles and replaced the word "Update" with "Up-date" in all threads with "update" in the title. That should prevent the security rule from being triggered for anyone clicking on any links for those threads.

IMPORTANT: The following words are also database manipulation commands, and should be avoided in your thread title when you post a new thread:

union|select|create|rename|truncate|load|alter
delete|update|insert|desc

Using any of these words in a thread title, will cause anyone clicking a link for that thread to trigger the security rule and be blocked from the site.

If you must use, for example, "update" in a thread title, then hyphenate it, like this: up-date

Using the word update in the body of a post should not (I think) be a problem, but avoid using the above words in thread titles.

Thanks,
Basil

 

[TR3driver]

Wow, what a hassle just to avoid something that should never have been coded in the first place. I realize it's not your doing, but still seems like a hassle just because some programmer was lazy (or worse).

 

[Basil]

Wow, what a hassle just to avoid something that should never have been coded in the first place. I realize it's not your doing, but still seems like a hassle just because some programmer was lazy (or worse).

It is a bit of a hassle but this is a common sort of problem on many web sites, unfortunately. Impossible to code for ever potential malicious thing hackers may try to use to exploit a web site, but these server-level rules help (some).

 

[dklawson]

I understand... now if I can just remember the "11 Words We Must Never Type in Titles". I am lucky to remember where I put my keys.

 

[Basil]

I understand... now if I can just remember the "11 Words We Must Never Type in Titles". I am lucky to remember where I put my keys.

Suddenly a George Carlin routine comes to mind (and no, I won't post it here, but most probably know of what I speak)

So far it seems the only word that's popped up as a real problem is "update"

 

[Gliderman8]

Suddenly a George Carlin routine comes to mind (and no, I won't post it here, but most probably know of what I speak)

So far it seems the only word that's popped up as a real problem is "update"

That’s the first thing I thought of.... those 7 words.

 

[dklawson]

Yep. That's why I counted the words. I was hoping it would be "7".

 

[TR3driver]

Impossible to code for ever potential malicious thing hackers may try to use to exploit a web site, but these server-level rules help (some).

I disagree. User input has no business ever being presented to a routine that parses database commands. As far as the database is concerned, user input is just a string of random characters.

Database commands should only ever be available to an authorized administrator.

But some programmers apparently don't understand the difference (or don't care).

 

[Basil]

I’ll take your word for it. All I know is these security rules are pretty standard fair.

I am not an expert on SQL injection attacks, but from what I understand, hackers continuously look for weaknesses in code that accesses a database. I agree that there shouldn't be any way for an attacker to conduct an SQL injection attack, but the fact is, SQL injection attacks are very common and a big problem. As I'm sure you know, the hacker looks for weaknesses in code that will allow them to deploy a malicious payload in a user form input to access the database and do bad things. VBulletin software has been around for many years but, while it is a well written piece of software, there have been many many security updates over the years to plug such potential weaknesses. These hacker idiots are continuously looking for ways to exploit web sites (I run a NAMI website using Wordpress and I'm constantly getting security updates for WordPress).

The security rules I have on my server are several hunderd in number and they are not just for this forum but for the entire server and for every web site on the server (I have more than BCF running on my server). I have two sets of security rules. One set is from COMODO and the other is from OWASP (Open Web Application Security Project). Here's an interesting article on SQL injections on the OWASP site: SQL Injection

I'd like to think that BCF is rock-solid and there is no way for a hacker to exploit it, but I've been doing this long enough to know that even the best written software can have weaknesses that hackers can find and exploit. That's why we constantly get "security updates" and why I have employed the security rules in question.

 

[TR3driver]

You're quite right, a very common problem and a standard way of protecting.

But you'd be surprised at how many times I lost the argument that existing code should be "fixed", because it didn't adequately check user input. Then later, after a customer found the flaw (usually by accident, not a malicious attack), I'd be the one stuck fixing someone else's code, because I was the one who pointed out it was wrong before it shipped. No good deed goes unpunished. Just one of the many frustrations that led to early retirement