Obfuscating or sanitizing errors can be tempting, but it’s usually a bad idea. You might think it’s better for a user if you dress up an error to look nice, or you might think it’s better for security if you don’t provide an error message at all.
How can a user hope to understand an error if you don’t make it look nice? What if an attacker uses an error to reverse-engineer how your system works?
There may be good arguments for hiding or disguising errors, but here are five good reasons to own them.
1. Accurate errors mean accurate bug reports
Recently, I was referred to a Git repository on a popular Git hosting service. When I navigated to the URL, though, I got a page announcing a 404 error.
In the HTTP protocol, error 404 means the page requested does not exist, so I started investigating the problem under the assumption that I’d been given an incorrect URL.
I analyzed the different components of the URL, verified the Git repo name and that my browser was functioning properly.
Everything seemed correct, but I was still getting a 404.
In the end, it turned out that the Git host had lied to me. The page did exist. I just didn’t have access to it. All I needed to do was request for the repo owner to add me to the project.
The problem? That’s not a 404. If anything, it’s a 403 Forbidden error, but it wasn’t an HTTP error at all. In fact, it wasn’t an error. It was the expected and correct result when someone without permission in the site’s database attempts to view a specific record.
I can only assume that the site programmers saw a fake 404 page as an easy way to neither confirm nor deny that a page exists. Plausible deniability is a useful security technique, but there are better ways to express it, such as “If this repo exists, then you do not have permission to view it. Otherwise, no such repo exists.”
The more you try to interpret an error for a user, the more likely it is for you to get inaccurate bug reports.
2. Errors promote self support
Errors provided in simple and descriptive language mean that anyone competent on a system can fix that error. An obvious and non-descriptive error like “login failure” places a brick wall in front of the user.
A descriptive error like “private key file not found” or “unable to reach Kerberos server” tells a user who understands how a process is supposed to work where the failure has occurred. The user’s investigation can start with the stated problem and possibly result in the user resolving the issue without bothering you for support.
When you obfuscate or hide an error, you’re inviting everyone to contact you for help whenever something goes wrong. If you don’t provide contact details for support, then you’re planting the seeds of helplessness and resentment in your user base.
3. Errors promote hardened systems
I get nervous about revealing too much information about my system to anybody who kicks my server often enough to get an error. It’s a valid and successful attack technique to discover errors and use them as context for how a system is configured.
However, it’s an equally valid and successful attack technique to build a profile of a system by the expected responses you get back from it.
In other words, should an attacker profile your system, they learn as much about it from what works as from what doesn’t work. Errors might provide an attacker a lead toward a known exploit, but so do everyday responses. No attacker is going to wait for an error message before attempting to exploit a vulnerability.
That’s not how attacks work. An attacker runs all known exploits against your system, using a script or an automated framework and hopes that one works. It’s just too much work to sit around and look for errors before making a move.
Knowing this, an admin’s job is to ensure that the system is protected against common attack techniques. Detect attacks as they happen, dynamically block an IP that’s the source of unusual activity and ensure that your software is up-to-date. Those are the appropriate defenses against attacks and none of them involve obfuscating error messages.
4. Errors for errors
Errors happen because something’s gone wrong. When you try to obfuscate an error message, you’re tacking on a new subsystem that is itself subject to error. So what happens when your error interception subsystem has an error?
It’s not errors all the way down, so at some point a real error is going to get through and then all you have is an error about an error and never the error itself. Not only do your users have no idea what’s gone wrong, but neither do you.
5. Open collaboration
Bugs can feel embarrassing if you’re not numb to them yet. You might feel like an error exposes you as a bad programmer or a poor sysadmin. The reality is, though, that nobody sees it that way. Everybody knows that technology is imperfect. Errors happen.
When you share errors with the world, there’s a high chance that someone out there will help fix them. You might be surprised at how motivated a user can get when something gets annoying enough.
And it often happens with or without your involvement. There are unofficial fixes, workarounds, mods and hacks for all manner of problems.
Your users are going to find and use those techniques whether or not you admit that the error even exists. So the choice is yours. You can help your users succeed (and accept that they can help you succeed), or you can ignore the problem and force your users to waste their time and energy hunting for an unofficial workaround.
One of these techniques breeds collaboration and mutual support.
The other breeds frustration, anger and resentment.
Errors are good
It’s true that not everyone appreciates a stack trace or core dump when an error occurs. Not all errors have to be ugly. You can make them look nice—you can probably prepend or append a helpful message telling users what they can try next when an error is encountered.
It’s vital to be friendly to users who don’t understand how or why errors happen. But it’s equally vital to understand that some errors are so bad that they’ll hop over your intended interception and also that providing accurate errors is important to a subset of users and can greatly benefit both you and the people using your application or service.
Photo by Ben Hershey on Unsplash
