Database Connections and Trust
Your Web application connects to a database. You supply the user name and password, establish the connection, and run your query. A very simple, easy to use, and essential component to web applications.
The database itself has very little awareness of where the application that made the connection is located. It does not necessarily know the purpose of the application. It may or may not know the real user who is using that connection. It’s not that it cannot, it is just typically not programmed to do so. It is at the beck and call of the application and will do whatever the application asks it to do.
One of the great reasons to use Database Activity Monitoring is to de-mystify that connection. These monitoring tools pay close attention to where the connection is coming from, what application is making the connection, what time of day it is, how much data is being moved, what queries are being run, what fails to execute, and on and on. This provides a very real benefit in detecting attacks and other types of misuse. There is a strong market for this type of tool because application developers rarely develop this capability within the context of the service they are providing.
Can this be done from within the database? Yep. Do people do this? Rarely to never. Should it be done? I contend that to some degree it should always be there. Much in the same way we provide range checking on database values, we should also have some degree of business consistency checking. But we don’t because it is typically not part of the scope of the application project to program the database to perform additional checking and verifications. Usually it is only scoped out to store data and provide some reports, just a basic repository for storage of data and application state. We have gotten to the point where we use Hibernate <http://www.hibernate.org/> to abstract the concept of a database altogether and further remove any native database visibility.
Give the database user name and password and it will give you everything you have permissions to do … and then some. It is set up to trust you. And why not, you gave it the right credentials! And the converse of that is the application developer views the database as some abstract object. Security of that object is someone else’s problem. The loss of visibility does not mean that the functionality is not there, or that it is not important, or that the application developer can ignore it.
What I am trying to say is the database is set up to trust the application connection and it should not be.
Whatever you gave the user who connects permission to do, it will do, whenever asked. But should you be accepting local connections? Remote connections? Ad-hoc queries? What stored procedure execution is appropriate? If the database is used in an SOA environment, or the omnipresent ‘hub-and-spoke’ model, how do those rules change per application connection? And unless you instruct the database to do more, to question the authenticity of the connection over and above access rights, it will not provide you any additional value in terms of security, data consistency, or data privacy. Why is it that application security, and quite specifically web application security, is so often viewed soley as a web application security problem? The application has a strong relationship with the database but typically does not have bi-directional trust enforcement or security.
For example, in production database environments we had a requirement that there would be no ad-hoc access under normal usage of the system. We would implement login triggers similar to NoToad.sql to prohibit this access via an ad-hoc administration tool. We had stored procedures built into our packages that recorded an audit event whenever a user was selecting more than some predetermined number of customer rows. But I think this was atypical, and these types of security constraints are not systemic, meaning they are often left out of the back end design.
The application is designed to serve a business function and we buy security products to monitor, assess and audit the business function externally.
Do you see where I am going with this? We can build security in systemically if we choose, and reduce the dependency on external security. We can and should do more to verify that the application that is connecting to the database not only has appropriate credentials, but appropriate usage. A database is an application platform, and an application in and of itself. This becomes even more important in a virtualized environment where some of the underlying network assumptions are thrown out the window. Hackers spend a lot of time determining how best to access and utilize the database not only because it typically contains the information they are after, but also it is an extraordinarily complex, feature rich platform. That means a fertile field of opportunity for misused trust relationships and insecure functions … unless you program the database to perform these verifications.
Andre Gironda Jun 19
Wow… what a mouthful. You should really outline some of these ideas. Sounds like you want to speak to the breadth and depth of your knowledge all at once, which is a lot for me to take in (mostly because of my limited internal database knowledge).
When I’ve seen controls around databases, it’s been a change control system where a coding standard of SQL statements were sent through a batch processing system. If certain tasks went past their allotted time, they were often backed out so the next tasks could go through (and the original change had to be re-planned and re-approved).
Developers typically want an ORM like Hibernate because they also want dynamic schema control/generation using annotations. To them the database is alive through the application — it’s an extension to the app. Certainly this doesn’t provide even a layer of extra security — there’s HQL injection just like there is SQL injection. Similar concepts apply to LINQ.
I’m very much looking forward to more articles from you like this — my knowledge of trust is all network, OS, and app. I guess I’ll have to read some of those books that Rich recommended…
What do you recommend for those just starting out?
Sharon Besser Jun 19
It was hard enough to follow-up with one writer now we have to deal with two. Welcome. Looks like fun.
First, the necessary full disclosure statement: I’m working for an application data security company. Our solutions covers the application and database stacks.
I agree with some of your arguments, with your permission, In order to develop the discussion, I wanted to ask you how do you compare / measure the isolated database security solution with theories such as the ADMP (see http://securosis.com/2007/12/17/definitions-content-monitoring-and-protection-and-application-and-database-monitoring-and-protection/)
“Products that monitor all activity in a business application and database, identify and audit users and content, and, based on central policies, protect data based on content, context, and/or activity.”
what is your definition of “external security”: is it a box located outside the application (without modifying any line of code), a vendor provided external tool (probably from another company that was acquired some time ago) or stored procedures built into a commercial product that requires the change of the application.
I think that we all share the same goal, I believe that the performing the tasks you are describing requires the protection of the application as well. No database is an island…