(or ...To Custom Error Page, or Not to Custom Error Page?)
Sherif wrote an interesting piece today on his blog titled "Why You Should Re-consider Custom Error Pages" and it got me thinking. I've seen a few web applications in "large companies" over the last several years both from the developer side, and now as a vendor working with web app security scanning tools - and there are two sides to this debate over custom error pages. Custom error pages actually serve two very distinct purposes - and I want to outline them here for discussion.
First off, it's probably most widely accepted that custom error pages (or "friendly" error pages) are a usability bonus for the user. When something goes south it's nice to give the user a sense that the administrator (or developer, as the case may be) has the issue under control and is working on a fix. The "oops, something went wrong, but don't worry we're working on it" page has become somewhat common in the SoMe (Social Media) landscape. That's all well and good, and making the user feel less disheartened is always a good thing - but there are actually other benefits here.
Secretly, security people like me love it when developers choose to custom-code error pages. Rather than giving a possible would-be attacker any more knowledge of the site by throwing some error dump to the browser it's significantly more "security conscious" to just throw a generic error page. Often times error pages have hidden nuggets of information an attacker can use against you - such as internal IP addresses, server names, connection strings (in the case of SQL Injection) or other useful information that can be used in the commission of the attack. Custom-coded error pages generally throw up a cute graphic and something to the tune of "Oops... sorry" and that's pretty much it.
That's two great benefits... but as those TV pitchmen say "but wait, there's more!" There's also an added benefit here that's been eluding even some of the more security-conscious developers. Generally you don't think of this issue (or benefit) until you've tried to scan a site that has this accidentally brilliant feature. What am I talking about? Try scanning a site with a web application security tool (it doesn't matter which you pick) when every "error" page (404, 500's, etc) throws back a status code 200. Maybe you're even sent back the index (or home) page! If my scanner is looking to execute some attack whereby I request a specific resource on the machine - even though it's not there - the server returns a status code of 200 ("everything's OK") and the home page - the scanner is left thinking that the attack was successful. This has a tendency to generate thousands of false positives. This kind of thing can frustrate some of the less determined attackers (I won't give them the hacker title here, they don't deserve it) and cause them to move on.
If no matter what you request the site sends back an HTTP/200 status code with some normal looking page - how do you tell that something worked ... or failed?! Now, arguably there are parameters you can tune, and tell your scanner that even though you get an HTTP/200 the fact that the "homepage" comes back means that the attack failed - but seriously - how many people actually get that deep into the configuration of these tools? What's worse, many of the freely available, or custom-written ones, don't even have that as an option!
Frustrating the "low hanging fruit" attackers is beneficial for many reasons including less noise in your logs - so this added side benefit comes in handy!
So, there you go... write those custom error pages! Demand that every site you work with behaves in this manner... no matter what ridiculous thing you ask it to fetch - make sure the response is "OK, no problem!"