Trust

Overly Paranoid?

By Adrian Lane

During a recent eBay auction, when clicking the "Pay Now" button for an item I had won, I was taken off the eBay site, to a third party merchant site. The merchant site was attempting to verify address information and shipping options, and then forward me to PayPal. I tried going back into my eBay account and making the payment directly to PayPal several times, in an attempt to avoid the third-party site, without success. It appears that eBay is allowing third party merchants to insert their own code and web sites into the checkout process. What's more, this particular merchant page was a mixture of secure and insecure content and some JavaScript. NoScript took care of the issue for me, but it leaves me wondering.

I am not sure if it is my heightened sense of post-DefCon paranoia, but this just seems like a bad idea to me. If I were a hacker, wouldn't I just love a way to insert myself into the payment process? With most security analysis processes, I start by examining trust relationships I can exploit. This tends to be fertile ground for logic flaws, and these trust points tend not to be closely inspected by users. If I can insert myself into an established trust relationship to launch my attack, I am far more likely to succeed, and this seems like an open window for me to do just that. Bogus image tags, XSS, XSRF, inline frames, or whatever attack du jour; it seems like a natural target for inserting myself between these two trusted entities. I am not saying that any particular merchant site is insecure at this time, but I am willing to bet that regardless of any vetting process third parties go through, their security is not uniformly as strong as eBay's and PayPal's.

In general, I have no relationship with any of the third party merchant software, so I have no reason to trust the sites or their security. I make purchases on eBay with PayPal because I have a basic trust in their sites, processes, and security teams. This trust does not fully extend to every one of their affiliated merchants and third party sites, now and in the future. Not only that, the third party site offers me, the buyer, no added value, only potentially decreased security.

From PayPal's own "Top Ten Safety Tips", which they provide with the Security Key, tip number nine is "Stay Safe on eBay: ... Pay safely using PayPal, the secure payment method that enables you to shop without sharing your financial information with the seller". But if the merchant has been linked into the process, and you have to go to a merchant site first, it is somewhat at the seller's discretion. And if the merchant site has been hacked, all bets are off.

I sent the question over to eBay and PayPal security and have not received a response, so I wanted to know what the community at large felt about this.

–Adrian Lane

Database Connections and Trust

By Adrian Lane

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.

–Adrian Lane