Saturday, February 27, 2016

Security threats associated with exposed server side error details

Security threats associated with exposed server side error details
This topic may be categorized under penetration testing and hacking for a website. According to Open Web Application Security Project (2014), there are many SQL Injection exploitation techniques that utilize detailed error messages from the database driver. Further in depth testing and code review may help determine possible vulnerabilities and minimize the risk.
Improper error handling is not only unpleasant for the end user, but also serves as a starting point for the hackers to define strategy by exposing high level and low level software components deployed to build an application. It may include how the website is logically built up from top to bottom along with database schema. If an expert attackers knows exactly the building blocks and DB schema of an application, he is half done stealing the confidential information you may be hiding from anonymous users.
All the software bundles provide developers with basic building blocks which may be used to do robust error handling. For example:
·         Apache is a common HTTP server for serving HTML and PHP web pages. By default, Apache shows the server version, products installed and OS system in the HTTP error responses. Responses to the errors can be configured and customized globally, per site or per directory in the apache2.conf using the ErrorDocument directive. In case of error, Apache can be configured to output hardcoded error message, a customized message, redirect to external or internal page using ErrorDocument directive. Administrators may configure AllowOverride using .htaccess file. For allowing ErrorDocument you need to set AllowOverride to All. ServerTokens and ServerSignature may be configured to hide server specific information in http errors.
·         Generally Microsoft technologies based web applications are deployed on Internet Information Services (IIS). In a typical .Net web application, developers may suppress the unhandled errors being exposed to users by custom error page. A .Net web application which shows yellow screen of error is built by novice team of developers. In some of the applications, error handling is taken very seriously using custom exception handling http modules. Along with custom error page a unique identifier is sent as a hidden variable to the client side, which end user may be easily instructed to share with support team. This unique identifier is generated by the custom http error handling module, and saved along with error information in multiple possible ways. Some the applications I have seen use third party frameworks like Elmah and Log4net for robust logging in flat text files and error database. A detailed low level application design defines what information is required by end user to do correction in input data and what else is to be hidden by the error handling modules assigning a tracking unique identifier.
Next time, when you are in development phase of a web application, remember that your responsibility to handle errors does not end with a try catch finally. There must be low level details specified and planned for well ahead. Some hacker on the other corner of this world is waiting for you to shirk work.

Apache Software Foundation. (2015, December 10). Log4net (Version 2.0.5) [Computer software]. Retrieved from
Aziz, A. (2012, April 13). ELMAH (Version 1.2.2) [Computer software]. Retrieved from
Open Web Application Security Project. (2014, August 8). Improper Error Handling. Retrieved February 23, 2016, from
Penn Computing. (2016, February 26). SWAT Top Ten: Improper Error handling. Retrieved February 26, 2016, from

The Apache Software Foundation. (2016). Apache Core Features. Retrieved February 26, 2016, from