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 Such details can provide hackers important clues on potential flaws in the site and such messages are also disturbing to normal users.

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: 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  When errors occur, the site should respond with a specifically designed result that is helpful to the user without revealing unnecessary internal details 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-or- minimizing-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_%28OTG- ERR-001%29