Filed under: Web and Application Security
What Errors Are
Error messages are a fairly standard part of the web that can provide useful information to developers to resolve issues or indicate to users that there is something wrong with a page. While smart developers and site admins will customize error messages to hide sensitive info, sometimes something as simple as a careless change to a configuration file can expose verbose HTTP errors – including 500-level errors that can contain normally-hidden details of your application. While this is okay for your developers to see – in order to resolve the error – these are not okay for external users to see.
Scenarios in Which You Might See an Error
Of course, errors are not desirable. Errors are more like the ugly blemish that haunt every app at some point and some are more serious than others. Detailed errors can provide contextual information pertaining to things like the server’s directory structure, the SQL queries being run, or the modules and libraries loaded by the application framework. By generating an error response, a hacker now has context for what creates a particular error state and also gains a little bit of extra knowledge about the site.
Why is This Useful?
Even seemingly unimportant or small bits of information can be very useful. With enough time and patience a hacker can use the initial leakage of information to probe further. Based on the knowledge gained from the initial error, they can dig deeper to see what other errors they can elicit. Much like a detective following a lead from a piece of evidence, a hacker can follow the knowledge gained from a piece of information to it’s conclusion. In all likelihood, they’ll come across another valuable piece of information via an error (if errors are completely unsuppressed) which will lead them down another path to explore and investigate. All this probing really puts a site at risk, as it increases the chances that a vulnerable piece of software (plugin, library, framework, etc.) is discovered. If a hacker can pinpoint that you’re using version A of X library with Y known vulnerability, then there is a very clear path to exploitation and causing serious damage.
Recon for Attack – Just like Real War
“Know your enemy” wrote Sun Tzu in the Art of War, and most would agree that it’s unwise to launch an attack on a target without doing some reconnaissance to find points of weakness and points of strength. This principle applies to web technologies as well. Hackers can use error messages to probe and determine areas of weakness within their target. Giving hackers the ability to create errors without penalty is incredibly valuable as it gives them free reign to scout your site and gear up for attack. If areas of weakness or vulnerability are found during the scouting process, then the site can be added to a list of vulnerable sites, which then can be attacked by others in the community. If finding errors is the first line of attack, then hiding those errors should be the first line of defense. By preventing hackers from gathering accurate information about your site or app, you keep them from gaining an upper hand. Suppressing error messages is part of anti-reconnaissance and a solid defense-in-depth strategy.
An Internal Conflict
On the surface, detailed error messages can be useful for developers to debug issues. In fact, in many cases developers like these messages as it makes their jobs easier. Detailed messages often point right to the source of a problem, even indicating which line of code or which method is problematic and in which file. Just as this little snippet of information is invaluable to a developer doing some debugging, this information is useful to a hacker who is trying to cause trouble. Quickly, we can begin to see a conflict arising between a developer and a security professional:
- Dev wants detailed error messages in the app because this makes his/her life easier
- IT wants non-detailed error messages because this makes his/her life easier – and it protects the company
- Without detailed error messages, dev’s job becomes more difficult, and more time/company money is spent debugging code
While the sysadmin-developer divide is nothing new, this is a sensitive area because security is coming into play. That means that security should take precedence, but it doesn’t mean that developers’ jobs need be made more difficult.
Some interesting articles involving information leakage
Solution with ServerDefender VP
Luckily, this type of recon can be prevented and developers jobs don’t need to be made more difficult. Here at Port80, we spent a lot of time thinking of the best way keep verbose error details out of the hands of hackers. The solution we came up with is very simple: don’t show verbose error messages. Over the last few years we’ve developed a complete web application firewall called ServerDefender VP that offers the ability to handle errors. We developed methods to handle errors in two ways:
- Spot and prevent verbose 500 HTTP errors from being outwardly displayed
- Mask all errors with a generic error message, so all errors will look the same to would-be hackers
We also included the ability to whitelist IP addresses. This means that if a developer needs to debug something, the sysadmin can add their IP to a list of excluded IPs. This tells ServerDefender VP to let those IP addresses bypass the error handling controls, therefore allowing users to browse the site without error messages being suppressed.
How does it work?
These capabilities are default features in ServerDefender VP and are powerful ways to prevent reconnaissance. Here’s what happens when ServerDefender VP encounters a 5xx HTTP error:
- User browses to a page
- An HTTP error is caused and generated
- ServerDefender VP catches the response before it’s posted
- Instead of showing the HTTP error status code, SDVP sends a generic error response. This can be not only a page that discloses no sensitive data, but even a response code that is normalized so that nothing can be inferred from it (e.g., 404 instead of 500).
- The end user now knows something went wrong, and can even be shown a helpful site-customized experience to get them back on track, but not specifically what
This error message can be customized to be anything, but most importantly it ensures that no valuable reconnaissance information is leaked; the error is suppressed by ServerDefender VP and never sent to the client. This error handling technique takes away the first line of attack and means that hackers won’t be able to find clues that make it easier for them to hack you. We’ll leave you with one more piece of advice from Sun-Tzu, that sums up SDVP’s attitude toward data-hugry hackers: “Be extremely mysterious..thereby you can be the director of the opponent’s fate.No Comments »