AppSec Blog

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!


Post a Comment


* Indicates a required field.