A little more on security and back doors

Following on from my previous post, I thought I'd talk a little bit about the designs of the projects that I am in charge of.  Now to any of my Microsoft superiors who may be reading this post, fear not.  I have never put any security back doors into my projects.  It'd never make it past a spec review anyhow.

Instead, I would like to talk a bit about front-end vs back-end interfacing with databases.  For example, we have a spam rules database with a web front-end to interact with it.  The front-end allows you to do inserts, deletes, modifications to existing rules and limited search queries.  It's a convenient interface.

But yet it is limited.  Sometimes the web server goes down.  Sometimes existing spam rules take a long time to load.  Sometimes doing a search returns thousands of queries and is nearly impossible to find the one I want.  In this case, searching the database itself makes sense.  I have much more flexibility doing a MySQL search and specifying the search parameters for rules that I want than I have with the web front end.  When I was a spam analyst, the web front end was all I needed.  But as I moved on from analyzing spam to doing research into spam in general, I needed to do more flexible queries.  In addition, if I ever wanted to modify a spam rule and the server was down, I could always do a manual db insert.

I call this manual db modification a back-door modification.  It's actually useful from time to time but it is more prone to error.  If I ever delete something but forget to specify which rule, such as drop * from spamRules (not the real table name), that would be a disaster.  But on the other hand, doing a search query and piping the results into another script I wrote to parse some headers / IPs is incredibly powerful.  With great power comes great responsibility.