Stored Procedures vs No Stored Procedures - Security Viewpoint

Question

For a web application database, from a security standpoint only, what are arguments counter to the point for an sp only solution where the app db account ha

Answer 1

It's an imperfect analogy, but I like to compare the tables in the DB's "dbo" schema to "private" data in OO terminology, and Views and Stored Procs to "public." One can even make a "public" schema separate from the dbo schema to make the distinction explicit. If you follow that idea, you get a security advantage as well as an extensibility advantage.

One account (not the web app's account) has dbo access and owns the database, and the web app connects using another account restricted to the public-facing structures.

Answer 2

The only possible argument against is that I have run into cases where certain statements cannot be effectively parameterized in an SP (and dynamic sql is required) and this gives you the possibility of in-SP SQL-injection. This is really a very narrow consideration however and it is a rare case. At least in PostgreSQL I have once in a while seen a few cases where this had to be subject to extra review.

On the whole even in these cases, I think that SP type approaches give you a benefit security-wise because they mean that the application can use generic anti-SQL-Injection mechanisms where it might not otherwise be possible, and your SP can be used by many applications. Additionally if all activity must go through SP's then you can reduce your exposure to sql-injection and centralize the audits for problems.

In general, the less a user can do the less security exposure generally there is. This means the less a user can do with an sql injection attack.

Stored procedures generally give better and more granular security than you can do without.

Answer 3

Let's take a system that needs to be really secure, say your company's accounting system. If you use procs and grant access only to the procs, then users cannot do anything other than what the proc does, ever. This is an internal control designed to make sure that the business rules for the system cannot be gotten around by any user of the system. This is what prevents people from making a company purchase and then approving the funds themselves opening up the door to fraud. This also prevents many people in the organization from deleting all records in the accounts table because they do not have delete rights except the ones granted from the proc which will allow only one delete at a time.

Now developers have to have more rights in order to develop, but they should not have more rights on a production machine ever if you want to consider security. True a developer could write a malicous sp which does something bad when put to prod. This same developer though could put the same code into the application version and be as likely to be caught or not causght as if they maliciously change a proc. Personally I think the proc might be easier to catch because it might get reveiwed separately from the code by the dbas which might mean the manager or configuration management person and the dbas had a chance to look at it vice just the manager or configuration management person. We all know reality is that no one pushing code to prod has the time to review each piece of it personally, so hiring trustworthy developers is critical. Having code review and source control in place can help find a malicious change or roll it back to a previous version but the use of sps vice application code are both at risk from developers no matter what.

The same is true for system admins. The must have full rights to the system in order to do their jobs. They can potentially do a lot of damage without being caught. The best you can do in this case is limit this access to as few people as possible and do the best you can in hiring trustworthy people. At least if you have few people with this access, it is easier to find the source of the problem if it occurs. You can minimize risk by having off-site backups (so at least what the admin breaks if they turn bad can be fixed to some extent) but you can never completely get rid of this risk. Again this is true no matter what way you allow the applications to access data.

So the real use of sps is not to eliminate all possible risk, but to make it so fewer people can harm the system. The use of application code to affect database information is inherently unsecure and in my opinion should not be allowed in any system storing financial information or personal information.

Answer 4

The biggest security advantage to not using stored procedures is clarity. You know exactly what an account can do, by seeing what access to tables it has. With stored procedures, this isn't necessarily the case. If an account has the ability to execute procedure X, that does limit the account to executing that and not hitting an underlying table, but X can do anything. It could drop tables, alter data, delete data etc.

To know what an account can do with stored procedures you have to look at the stored procedure. Each time a sproc is updated, someone will have to look at what it does to make sure that something didn't get "accidentally" placed in it. The real problem with security in sprocs comes from inside the organization, not from rogue attackers.

Here's an example:

Let's say you are trying to restrict access to the employee table. Without stored procedures, you just deny access to the table. To get access someone pretty much has to blatantly ask you to grant permissions. Sure they could get you to run a script to grant access, but most people at least try to review a script which alters the database schema (assuming the script doesn't update a sproc, which I will talk about below).

There are potentially hundreds of stored procedures for an application. In my experience, they get updated quite frequently, add a field here, delete one there. For someone to review the number of update procedure scripts all the time becomes daunting, and in most organizations the database team starts to only quickly look at the procedure (or not look at it all), and move it along. This is where the real problem comes in. Now, in this example, if someone on the IT staff wants to allow access to a table, that person just needs to slip in a line of code granting access or doing something else. In a perfect world this would get caught. Most of us don't work in a perfect world.

The real problem with stored procedures is that they add a level of obfuscation to the system. With obfuscation comes complexity, and with complexity comes ultimately more work to understand an administrate the underlying system. Most people in IT are overworked and things slip through. In this instance you don't try and attack the system to gain access, you use the person in charge of the system to get what you want. Mitnick was right, in security people are the problem.

The majority attacks against an organization come from the inside. Any time you introduce complexity into any system, holes appear, things can get overlooked. Don't believe it, think about where you work. Go through the steps about who you would ask to get access to a system. Pretty soon you realize that you can get people to overlook things at the right moment. The key to successfully penetrating a system with people involved is to do something which seems innocuous, but is really subversive.

Remember, if I am trying to attack a system: I am not your friend; I have no interest in your kids or hobbies; I will use you in any way necessary to get what I want; I don't care if I betray you. The idea of "but he was my friend and that's why I trusted him to believe what he was doing was correct," is no comfort after the fact.

Answer 5

From a security point of view only, I can't see any advantages a non-SP approach would have over an SP approach because:

• you have to grant permissions directly to the underlying tables etc
• with a sproc, all the real-underlying schema information can be encapsulated/hidden away (SPs can be encrypted too)

Answer 6

Most of the answers here specify the security advantages of using stored procedures. Without disregarding those advantages, there are a few big disadvantages that haven't been mentioned:

• The data access patterns are sometimes much more important than a specific procedure that is being done. We want to log/monitor/analyze/raise alerts/block who access the data, when, and how. We can't always get this information when using stored procedures.

• Some organizations may have tons of stored procedures. It is impossible to review all of them, and it may make more sense to focus on tables (especially when considering that stored procedures may be very complex, have bugs, and introduce other security issues).

• Some organizations may require a separation of concerns. Database administrators (or anyone who writes stored procedures) are not always part of the security personal. It is sometimes necessary for the security personal to focus only on the data simply because they are not responsible for the business logic and the guys that do write the business logic, are not completely trusted.