Download Error Message Handling

Error Message
Handling

Improper handling of errors can introduce a variety of security problems
for a web site.

The most common problem is when detailed internal error messages such
as stack traces, database dumps, and error codes are displayed to the
user (hacker).

These messages reveal implementation details that should never be
revealed.

These errors must be handled according to a well thought out scheme
that will:

provide a meaningful error message to the user

diagnostic information to the site maintainers

no useful information to an attacker
Example

Even when error messages don’t provide a lot of detail, inconsistencies in
such messages can still reveal important clues on how a site works, and
what information is present under the covers.

For example, when a user tries to access a file that does not exist, the error
message typically indicates, “file not found”. When accessing a file that
the user is not authorized for, it indicates, “access denied”.

The user is not supposed to know the file even exists, but such inconsistencies will
readily reveal the presence or absence of inaccessible files or the site’s directory
structure.
Good error handling practices


Good error handling mechanisms should be able to handle:

any feasible set of inputs

while enforcing proper security
Simple error messages should be:


produced and
logged so that their cause, whether an error in the site or a hacking
attempt, can be reviewed.
How to determine vulnerability

Thorough testing

Code review
How to protect?
Errors should be documented including:
1.
2.
the types of errors to be handled and for each, what information is
going to be reported back to the user
what information is going to be logged
3.
When errors occur, the site should respond with a specifically
designed result that is helpful to the user without revealing
unnecessary internal details
4.
The ability to detect/track failures
Server log Viewing Guidelines
A good approach to keep up to dated with the server error logs is to keep
periodically checking on the Log Viewer for server errors.

As QA, we should check the log viewer at the end of every sprint, and share the
number and type of errors logged via a generic ticket with the development
team.

Another good exercise would be to lookup the error logs before starting to test a
new feature/task. When you are done with testing the feature/task, check the
error logs again, if there are any error logs that appeared during the testing of
that feature, share the findings with development team within that particular
task's comments section. This can help us pinpoint the change that set off the
error logs.

Another good practice would be 'Set an Alarm' on daily basis, so that the error log
reports can be sent to our email on hourly/daily/weekly basis.

Ideally, the number of error logs should reduce with every sprint. If not, then we can
bring this point into notice to our team and TAG.
The URL is as follows:
http://logviewer.togethersupport.co.uk/
Screens of death

A Yellow Screen of Death (also called YSoD) occurs when
an ASP.NET web application encounters a problem and crashes.[4] It
also appears on the browser Mozilla Firefox when there are errors in
reading the .xml web format.

It can be caused by unhandled exceptions in your code, by
making requests to resources that do not exist, etc.
References

https://mvcdeveloper.wordpress.com/2013/06/26/preventing-orminimizing-yellow-screen-of-death-in-asp-net-mvc/

https://www.owasp.org/index.php/Improper_Error_Handling

https://www.owasp.org/index.php/Testing_for_Error_Code_%28OTGERR-001%29