Top 25 Series – Rank 16 – Information Exposure Through an Error Message

Yesterday, Frank talked about dealing with unusual or exceptional conditions. Today’s topic, “Information Exposure through an Error Message” (CWE 209) [1] is closely related. After all: What should you tell the user if an error happens? First of all, whatever you tell the user should be useful to the user. Telling the user about a failure of your database only helps the user if the user is going to fix it for you. Well, in some cases, the error message may include the database username and password, so maybe the user has everything they need to fix it for you.

Sadly, these “overly helpful” error messages are way too frequent. In its simplest case, it may be a path disclosure. For example, a quick google query [2] reveals site after site with badly configured PHP include paths or missing files. In this case, the exposure is limited, but still potentially serious if another vulnerability can be used to read or write files from the file system.

More serious information exposure usually comes with failed database connections that reveal the username and password or SQL failures that point to SQL injection flaws.

But the real question: What should I tell the user instead. Sticking with the basic rule of application security of users being (a) evil and (b) unwilling to fix your database for you, you should tell them as little as possible. A generic error page usually works best. Tell them what happened: “Sorry, we can’t process your order right now”. Make them feel like everything is under control: “We are currently performing maintenance”. And finally, tell them what to do: “Please try again in 30 minutes”. Don’t tell them to “try again later”. For some people “later” is 5 seconds and the last thing you want to have happening if your database is under stress is a user who keeps clicking “reload”.

One argument you may hear from developers: “I need error messages for debugging”. First of all, you should not use the live site to debug. That’s what we have development sites for. And if you ever need to debug on a live site: Use the error log!

[1] http://cwe.mitre.org/data/definitions/209.html
[2] http://tinyurl.com/yaeakxk

Argument for Database encryption in web apps

I regularly get consulted on various web application security issues and defensive strategies. One of the recent “frequently asked questions” is around database encryption of web application. My answers to these kind of questions usually lead to awkward looking faces. I always start off asking more questions about the requirements, “Who are you trying to protect the data from?” and “What data are you trying to protect?”  The  answers to those questions are usually good indicator whether the person is on the right path or not.

In most cases, database encryption does not prevent the hacker from accessing the backend database via an application compromisse. The reasoning is very simple. If the web application needs to be able to access the data for normal operation and hackers are able to compromise the application, the hackers can essentially access the same data by controlling the applicaton (attacker owns the application). Encryption does not prevent a hacker to access the backend database if the hacker can control the application.

Some may argue that if the database encryption is per user based, then one user’s compromise does not lead to compromise of another user’s data. That is very valid but that usually requires authentication of the user to some backend pieces (or the database itself). Maybe authentication alone is sufficient for the security requirement? The database can provide access control based on user’s identity so one user’s compromise does not lead to access to other user’s data.

You might think I am an anti-encryption person. The fact is – I am not. Encryption totally has its place for web application security reasons. Asymmetric encryption usage to protect data that is “one way” in nature is a good example. As a retail store trying to store the user’s credit card details for recurring monthly payment, the data should be encrypted with asymmetric encryption so that the Web frontend can never read the data back but another party with another related key can. Also, there are numerous other scenario where encryption should be used, such as backup, protecting against rogue DB administrators and against physical theft of database machine.

I often recommend a threat risk assessment before deciding on the database encryption solution. That would allow you to quickly understand the threats that affect the web application and also  possible countermeasures that can help protect against the threat. Due to the cost of deploying and maintaining database encryption, I am seeing very limited deployment of database encryption, most folks tend to turn to other alternatives for risk mitigation.

Encryption is a useful defensive technology that can help protect the web application but it is not a silver bullet, blindly deploying it may not address any threats that you are trying to mitigate. The managers and auditors tend to request these technologies to be deployed to defend against web application compromise after seeing another competitor getting compromised thru web application security flaws (eg. SQL injection). Encryption is likely not the best choice of defensive technology given the scenario.