Proper error handling is part of making a high-quality software system and assists in hardening our systems to attack. Logging assists not only in debugging, but when investigating security events and incidents. This piece features a timesaving checklist which establishes a universal list of error handling and logging requirements to facilitate use in all web applications, APIs and other software systems.
Error Handling and Logging Checklist
All errors should be caught and handled gracefully; there should never be a stack trace or database error on the screen. This keeps attackers from being given extra information to use against us when creating their attacks. The checklist can be used for all personnel or contractors responsible for development and maintenance of custom software at your organization. This worksheet may also be used as an error handling and logging policy, or as part of a secure coding guideline or standard.
Error handling basics
- All application errors must be “caught” and handled; a system error must never be left “unhandled.”
- Use of a catch-all mechanism (global exception handling) is required to ensure unexpected errors are always handled properly.
- System information, such as stack traces or other crash information, should never be revealed to the user or potential attackers. You must always provide the end user a generated error message.
- Error messages should reveal as little as possible. Ensure they do not “leak” information, such as details about the server version, patching levels or which specific characters failed input validation.
- Do not reveal whether it is the username or password that is incorrect when there is a login error, as this allows for username enumeration.
- Always “fail safe” or “fail closed;” do not “fail open” or to an unknown state. If an error occurs, do not grant access or complete the transaction; always roll back.
- Security-related errors (login fails, access control failures, server-side input validation failures) should issue a system alert. Ideally, log files will feed into an intrusion prevention/detection system or an application SIEM. This can be tested by running a vulnerability scanner against your application, it should cause events that trigger logging.
What and when to log
- System logs must not contain sensitive information, such as credit card numbers, personally identifiable information, classified information, health information, etc.
- Login fails and errors should be logged. The value of the password field should not be logged.
- Brute-force attempts should be logged (defined as 10 or more successive failed attempts to login in under 1 minute, or 100 or more failed attempts in one 24-hour period).
- All security-related events. Examples: a user being authenticated, a user being locked out after several failed login attempts, an unaccounted-for error, input validation errors.
Error information to include in your logs
- What type of event occurred (why this event is security-related/name for event);
- When the event occurred (timestamp);
- Where the event occurred (URL);
- The source of the event (IP address);
- The outcome of the event; and
- If possible, the identity of any individuals, users or subjects associated with the event.
* You may, of course, log more than what is listed above.
DOWNLOAD: DevSecOps Best Practices Checklist
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.