Try not to include unintended backdoors4th May 2016
I've been using a product recently that has its own simple programming language. As with Office VBA, it can really add benefit, even if the majority of users will never use it. It's the 80/20 rule - 80% of people only ever use 20% of the features.
One of the functions allowed execution of SQL statements. There are arguably valid reasons for this and I also knew that it executed within a restricted role, but its security relies on the fact that no one will do anything dumb like adding db_owner.
But....there's always a BUT.
When it comes to security there are two critical rules you need to bear in mind;
- Never trust any input
- Assume people will do dumb things
What if someone did start changing database permissions for whatever reason andat the same time someone decided to enable and execute xp_cmdshell?
At the end of the day, when you're adding features to a product, think about how it could compromise the product and will customers even use it?
Just because you can add powerful features doesn't necessarily mean you should. It could end up being an unintended backdoor.