Your Web application connects to a database. You supply the user name and password, establish the connection object and run your query. 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 are going to pay close attention to where the connection is coming from, what application is making the connection, what time of day 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 or other types of mis-use. There is a strong market for this type of tool because the application developer did not develop this code 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 have 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.
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, viewed soley as a web application security problem? The application has 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 oft 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 to do so 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 use. 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 determine how best to access and utilize the database because it not only contains the information they typically are after, but 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.
