Is there a good security and access management strategy to manage business logic validation rules that are stored as code in a database data table?

Question

My needs are very similar to this question about where to store business logic and this question about managing SQL code in a data table. But I would like more specific tips on how to manage the risks of SQL injection and Sandboxing that are alluded to in the answer to that second question.

My applications deal with data submissions that involve thousands of validation rules which need to be updated frequently. I would like to manage these rules as error conditions (formatted as SQL "WHERE" clauses) stored in a data table (ex: "Total != Column1 + Column2"). I would like analysts skilled in SQL to have access to directly insert and update these business rules, either in Management Studio or through an intranet application. One or more intranet applications or SQL processes would then use the error clauses in that table to validate data stored in other tables in the database.

• Is it fundamentally a bad approach to save arbitrary code to a database, even if access to that table is restricted to a small number of users?

• As my applications execute SELECT statements using the retrieved WHERE clauses, is there an effective, reliable way to limit the access rights of any malicious code pulled from the database? (I'm not confident that I can reliably sanitize a retrieved WHERE clause.)

• Is there a better place to store frequently updated business logic, that is similarly simple to manage, but with better security?

• Where can I go to find general principles about managing executable code in a database?

Answer 1

Given this statement of yours:

I'm not confident that I can reliably sanitize a retrieved WHERE clause.

The answer to the following question is "yes."

Is it fundamentally a bad approach to save arbitrary code to a database, even if access to that table is restricted to a small number of users?

Don't rely on restrictive access privileges. An attacker can cause mischief (at least denial of service) using only SELECT privilege -- or even no privilege at all.

I agree with the comment from @WayneConrad, that you would be more secure if you design your business logic in a DSL, and then write code to interpret your own DSL and convert it into a limited set of WHERE clauses. By parsing and validating your own DSL, you have a greater likelihood of blocking malicious code (unless your DSL becomes too flexible).

You're going to have to write a parser and validator, either for SQL or for a DSL. There's no other way to do this with any kind of security.