Editorials

SQL Injection Hack Attack — Poor Coding Techniques to Blame

Video: SQL Server 2005 Jobs and Tasks
SelectViews special – how to work with SQL Server 2005 jobs, tasks and more. We’ll look at monitoring the job system, seeing what the status is, demo the steps to add a TSQL job (specific demo) and a lot more. This is a different format show – would love to have your feedback!

> Watch the show here

Other Video Programs/Shows available:
[Watch] SQLonCall – Creating Standards for Your SQL Server
[Watch] SelectViews – Accidental DBA Tips II, Security, Data Masking and more

Looking for a Career Change?
Have you seen our job boards? More than 107 jobs specifically working with SQL Server, 100’s more in other areas. The cool thing is that you can post your resume (free) too – and YOU get to determine who contacts you. When someone likes what they see in your resume, they contact you through the system, then you decide if you want to talk with them, release your contact information, etc. You can browse posted jobs, post new jobs and completely control you career search. Check it out here. If you’re interested in posting jobs to this most outstanding community, start here.

SQL Injection Hack Attack — Poor Coding Techniques to Blame
There are SO many people writing about this whole IIS hack attack that I wrote about yesterday. What’s odd is the very few of them that get it. I’ve seen the issues blamed on everything from SQL Server not having granular-enough permissions controls to flaws in the OS. I don’t get it. This is just about coding techniques, nothing more. It’s not a "feature" or "bug" being exploited.

When you accept input from a user and pass it blindly to the database engine, you are asking for trouble. When you don’t control the input, don’t control how it’s presented to the engine for processing, you’re asking for trouble. It really is that simple.

It’s too easy for people to build sites with "dynamic SQL" – making changes to the SQL statements on the fly. "Select * from " + user_input is asking for trouble.

It’s simple. if your applications accept input from users, you need to make sure you’ve taken steps to properly pass information from your application to the server and back again as you display it. If you’re not doing this now, if you have not built this into your application design, review and development processes, you’re asking for people to exploit your system. If you’re not sure – find out. Learn what was built into the application. Consider using a tool to stay on top of new techniques and approaches. Hacker Safe is one such tool – take a look at what they’re doing and you’ll get a great idea of the types of things to be aware of. (Not affiliated)

Featured White Paper(s)
Optimizing your SQL Server Infrastructure: Good Ideas, Bad Ideas
In the first chapter of the eBook SQL Server Infrastructure Optimization, “Traditional Challenges and Their Impact,” the auth… (read more)