SQLStarters

Very recently I was working on a customer databases, when I more or less stumbled on a something I had not noticed before. Apparently at some point the latest version of SQL Server (I was working with Azure SQL DB) had a new security enhancement added into it called Feature Restrictions. As this was something I had not heard about before, I figured this would be a good opportunity to dig in and learn more about it.

Note: As I was finishing up this post to add links and such, I noticed that the official documentation from Microsoft regarding Feature Restrictions has completely vanished.

What are Feature Restrictions?

Feature restrictions are a recent security enhancement aimed to help protecting your database against SQL injections. At the moment of writing this post, it’s still very basic allowing only to disable 2 features. Error messages and use of WAITFOR in TSQL. Considering that these two are fairly commonly known methods for doing blind injections, this selection of features does make some sense.

One thing to note about the Feature Restrictions is, that they’re not exactly airtight. However having something is often better than not having anything at all.

How to use Feature Restrictions

There is a relatively simple syntax for adding and dropping feature restrictions.

sp_add_feature_restriction <feature>, <object_class>, <object_name>
sp_drop_feature_restriction <feature>, <object_class>, <object_name>

The accepted parameters are:

• Feature (WaitFor or ErrorMessages)
• Object Class (User or Role)
• Object Name (Name of the User or Role)

My thoughts about Feature Restrictions

I think that having the ability to turn features on and off for specific users or roles is absolutely great, however the first version of Feature Restrictions does leave room for improvements. Not sure what it means that all the documentation for the Feature Restrictions suddenly vanished, but it might have to do with the maturity of the first release.

I sincerely hope that Microsoft does continue to develop the Feature Restrictions further, at least I can see some use for such solution. For example there’s plenty of applications out there that are used in production but not developed, or fixed, at this point. Having this kind of option to limit some of the more vulnerable features is a decent option.

And when I say decent, it’s just that. The best option would be to follow the best practices and guidance around database and application development to actually make applications more resistant to injection type of attacks. Considering that the first public discussions around SQL Injections started before year 2000, it’s disheartening to see it hold it’s position as a top vulnerability year after year.

On a positive note, thanks to it’s 20+ years of existence there is no shortage on material that teaches you how to prevent SQL injections.