If you've read the IT press at all these days, you know that SQL Injection (SI) attacks are very common and can be devastatingly effective. In fact, SI attacks-equally easy to execute against Oracle, MySQL, IBM DB2, or Microsoft SQL Server-are among the most common hacks on the Internet today. If a web application runs a relational database on the backend, it can be subject to an SI attack, which ironically, is among the easiest web hacks to prevent.
While plenty of SI attacks hit SQL Server database, Microsoft has done much to strengthen and reinforce SQL Server's attackable surface area. In fact, in the last couple releases, SQL Server has had fewer security holes and critical flaws than the other leading database platforms. After the SQL Slammer virus of the early 2000s, SQL Server made security a huge aspect of its feature set, and, as a database, is ahead of the pack in terms of security features. It is SQL Server users- its DBAs, developers, and IT managers-who bear the blame for security hacks that succeed against their systems.
So what is SI? An analogy might explain the ease of defending against an SI attack better than a full technical description (For a technical description, visit http://en.wikipedia.org/wiki/Sql_injection). Imagine you're driving home from work and see all the doors and windows open at a neighbor's house. You peek out the window as you lock up for bed that night. All their doors and windows are still wide open. You get ready to leave for work the next morning and see your neighbor driving away with all the doors and windows completely open. A few days later, the house is burglarized. Well, no wonder! They never even shut the door, let alone lock it. They'd probably be safe and secure today if they'd taken that simplest of steps.
SI is practically the same situation. All it takes to prevent SI is to ensure your web applications test for allowable values in their input fields, and send their own error messages, rather than the default. SI is ridiculously easy to prevent, and if I managed a team where this happened, I'd fire the responsible parties, on both the development and administration teams. We know as much about preventing SI attacks today as we did the very first time they occurred. If it happens to you-just like a burglary in a house where the doors are never shut-you must blame yourself, not the locks on the doors.
Microsoft has implemented many new and improved security features in the wake of the SQL Slammer virus. Their entire development process for SQL Server includes rigorous security checks. When SQL Server is installed today, most security holes and surface areas have been closed off by default, requiring the DBA to consciously open them up after installation.
There also are a few best practices to keep in mind. First, as with disaster recovery, you should plan for the inevitable attack ahead of time. To prevent security breaches, ensure that applications and services run with the least possible privileges. Monitor login activity and raise an alarm when too many failed logins occur within a certain time period. Make sure applications run under their own account, not SA, and that guest accounts and the public role are dropped or not available. Finally, disable any system and extended stored procedures on your SQL Servers that aren't explicitly needed to support production operations.
Remember, SI attacks are common, but they're also very easy to prevent. Don't let it happen to you. You'll have only yourself to blame!