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.
References
Apache Software
Foundation. (2015, December 10). Log4net (Version 2.0.5) [Computer software].
Retrieved from https://www.nuget.org/packages/log4net/
Aziz, A. (2012, April
13). ELMAH (Version 1.2.2) [Computer software]. Retrieved from https://www.nuget.org/packages/elmah/
Open Web Application
Security Project. (2014, August 8). Improper Error Handling. Retrieved February
23, 2016, from https://www.owasp.org/index.php/Improper_Error_Handling
Penn Computing. (2016,
February 26). SWAT Top Ten: Improper Error handling. Retrieved February 26,
2016, from http://www.upenn.edu/computing/security/swat/SWAT_Top_Ten_A7.php
The Apache Software
Foundation. (2016). Apache Core Features. Retrieved February 26, 2016, from http://httpd.apache.org/docs/2.2/mod/core.html
No comments:
Post a Comment