I recently gave a SQLSaturday talk in New Mexico for an audience of about 30. The focus of my talk was development, and I touched on the security advantages of using stored procedures. When I asked how many folks in the audience used stored procedures to protect their environment against code injection attacks, only a couple of hands went up. I was taken aback by not just the absence of this practice, but the general absence of interest in the audience. What do you think? Take our quick poll on stored procedures Much is made of the conflict points between the DBA and developer roles. Some of these problems we’re just going to have to live with, but there are others where it’s common sense for both DBAs and developers to be on the same page, and security is chief among these. And in this arena, one of the lowest-hanging fruits in terms of collaboration is the use of stored procedures. Code injection attacks are the #1 security problem that your environment faces. As a DBA or a developer, it is in your best interest to advance this basic best practice with your team. Why? Stored procedures, because they cache the execution plan, can improve your system performance, for one. But focusing back on the main reason: The stored procedure enforces parameters on data input from applications that can prevent damage from malicious code injected by a cyberthief or vandal. A stored procedure gets executed in the same way as a pre-written SQL statement, the big difference being that the pre-written SQL statement will not discriminate about what kind of information gets entered into a field, only placing a variable. In the case of a table full of valuable customer data, malicious code can be inserted instead of say, your customer’s name. Stored procedures allow you to bind input to a specific data type, so it will look for an actual date in a date field or expect text info rather than an integer in a name field—validating what’s going into your database. Stored procedures close an important Achilles’ heel in your system, protecting the point of vulnerability where code injection can occur. There are few DBAs or developers who want to spend their day investigating where the point of penetration was while you sweat through backup and recovery mode. The learning curve for using stored procedures is more than forgiving enough to justify DBAs and developers getting together on this issue. But enough about what I think. We’d love to hear from the SQL Server community. Click here to take our poll about stored procedures. We’ll address the results in a future post.
↧