Saturday, September 13, 2008

SQL Injection Nonsense

I know a whole gobs of blogs have been talking about the SQL injection issues and all the fun stuff recently. I don't generally get into these security discussions as they're really not my focus. Don't get me wrong it's an important subject but I feel like there are plenty of other people out there tooting this horn and presumably know a crap some more than I on the subject. I'll be honest for the last 4+ years I have worked completely inside our firewall on the intranet so security is a bit different for us. One thing I keep finding myself questioning though is how many of us are putting ourselves at risk unnecessarily? I'm not talking about not using cfqueryparam here I am talking about the datasource and the database itself. Is your CF server using an account with the appropriate security level? Lets be honest here 80% of us are using sa or some account with entirely too high of privileges for what it is being used, what a dead brained move. If you are using sa or some other admin level account stop it and you stop half the threat. You don't even need to change code just the data source in the Admin. Even if for some reason your web app needs to control the database at some crazy level create specialized datasources for that section of the application. Datasources that are used on a publicly accessible portions of a website should be restricted as much as possible.

2 comments:

TJ said...

Adam,

While your advise is wise (and should absolutely be heeded), my experience has been that none of the SQL Injection attacks I've personally seen have a user that has elevated privileges. As a matter of fact, 100% of them have been datasources using a user account that is specific to that database.

My lesson learned was to be proactive and go back and offer to resolve known security issues in old code. Clients may not always opt to pay for this, but then it becomes their decision.

Security is about code, app configuration and network. Until all over these aspects are scrutinized and best practices are put into place the solution will be at risk.

What makes me laugh are how many companies still have port 1433 wide open to the internets. Didn't these people learn anything from Code Red?

Aral said...

Preventing SQL injection isn't rocket science nor the realm of specialized knowledge. Simply: do not trust user-entered data and escape everything and you'll be fine. It's worrisome that many developers do not take these simple steps.