loading...

Pushing Left, Like a Boss — Part 5.9 — Error Handling and Logging

shehackspurple profile image Tanya Janca Updated on ・3 min read

Pushing Left Like a Boss (23 Part Series)

1) Pushing Left, Like a Boss: Part 1 2) Pushing Left, Like a Boss! -- Part 2: Security Requirements 3 ... 21 3) Pushing Left, Like a Boss! -- Part 3: Secure Design 4) Pushing Left, Like a Boss: Part 4: Secure Coding 5) Pushing Left, Like a Boss — Part 5.1 — Input Validation, Output Encoding and Parameterized Queries 6) Pushing Left, Like a Boss — Part 5.2 — Use Safe Dependencies 7) Pushing Left, Like a Boss — Part 5.3 — Browser and Client-Side Hardening 8) Pushing Left, Like a Boss — Part 5.4 — Session Management 9) Pushing Left, Like a Boss — Part 5.5 — File Uploads 10) Pushing Left, Like a Boss — Part 5.6 — Redirects and Forwards 11) Pushing Left, Like a Boss — Part 5.7 — URL Parameters 12) Pushing Left, Like a Boss — Part 5.8 — Securing Your Cookies 13) Pushing Left, Like a Boss — Part 5.9 — Error Handling and Logging 14) Pushing Left, Like a Boss — Part 5.10 — Untrusted Data 15) Pushing Left, Like a Boss — Part 5.11 — Authorization (AuthZ) 16) Pushing Left, Like a Boss — Part 5.12 — Authentication (AuthN), Identity and Access Control 17) Pushing Left, Like a Boss — Part 5.13 — HTTPS only 18) Pushing Left, Like a Boss, Part 5.14 Secure Coding Summary 19) Pushing Left, Like a Boss - Part 6: Threat Modelling 20) Pushing Left, Like a Boss - Part 7: Code Review and Static Code Analysis 21) Pushing Left, Like a Boss - Part 8: Testing 22) Pushing Left, Like a Boss - Part 9: An AppSec Program 23) Pushing Left, Like a Boss - Part 10: Special AppSec Activities and Situations

**Previously published on my Medium blog, SheHacksPurple.

All errors should be caught and handled gracefully; there should never be a stack trace or database error on the screen. Not only so that we look like professionals, but so that attackers are not given extra information to use against us when creating their attacks. When errors happen, an application should never fail into an unknown state, it should always roll back any transaction it was performing, and ‘close’ anything it may have opened. Such a situation should also always be logged, so that if an incident were to arise incident responders would have something to work with when they investigate, and so that auditors can verify that the system is and has been working correctly.

In Hong Kong, at “The Peak”.

Errors:

  • All application errors must be ‘caught’ and handled, they can never be left ‘unhandled’.
  • Having a catch-all mechanism (global exception handling) is highly advisable, to ensure unexpected errors are always handled properly.
  • Internal information, stack traces or other crash information should never be revealed to the user or potential attackers.
  • Error messages should reveal as little as possible. Ensure they do not “leak” information, such as details about the sever version or patching levels.
  • Do not reveal if it is the username or password that is incorrect if 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.
  • Login fails and error should 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.

The following information must be contained 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.

** If the IP comes from X-Forwarded-For header do not forget to properly validate it, as it could have been tampered with. Special thanks to Dominique Righetto for this point! **

You can, of course, log more than what is listed here.

More of Hong Kong, a place which is unlike any other.

Using and Protecting Your Logs

  • Log files and audit trails must be protected, even the backups.
  • Ideally logs are all saved into the same space, in the same format, to be easily consumable by a SIEM or other security tools.
  • Only authorized individuals should have access to logs.
  • Logs should be stored in an encrypted format.
  • Logs should be accessible by your incident response team.
  • Logs should be stored on a secure server or other secure area.
  • Log files must be incorporated into your organization’s overall backup strategy.
  • Log files and media must be deleted and disposed of in the same way you would dispose of any sensitive information.

For more information on this topic the new OWASP Top Ten (2017, Item #10) contains detailed advice on this topic.

Reminder; never log Personally Identifiable Information (PII) or anything else sensitive such as SIN, passwords, or dates of birth.

For more detailed information on this and so many other application security related topics please check out the extremely helpful “OWASP Cheat Sheets” project.

Up next in the ‘Pushing Left, Like a Boss’ series: Untrusted Data.

Pushing Left Like a Boss (23 Part Series)

1) Pushing Left, Like a Boss: Part 1 2) Pushing Left, Like a Boss! -- Part 2: Security Requirements 3 ... 21 3) Pushing Left, Like a Boss! -- Part 3: Secure Design 4) Pushing Left, Like a Boss: Part 4: Secure Coding 5) Pushing Left, Like a Boss — Part 5.1 — Input Validation, Output Encoding and Parameterized Queries 6) Pushing Left, Like a Boss — Part 5.2 — Use Safe Dependencies 7) Pushing Left, Like a Boss — Part 5.3 — Browser and Client-Side Hardening 8) Pushing Left, Like a Boss — Part 5.4 — Session Management 9) Pushing Left, Like a Boss — Part 5.5 — File Uploads 10) Pushing Left, Like a Boss — Part 5.6 — Redirects and Forwards 11) Pushing Left, Like a Boss — Part 5.7 — URL Parameters 12) Pushing Left, Like a Boss — Part 5.8 — Securing Your Cookies 13) Pushing Left, Like a Boss — Part 5.9 — Error Handling and Logging 14) Pushing Left, Like a Boss — Part 5.10 — Untrusted Data 15) Pushing Left, Like a Boss — Part 5.11 — Authorization (AuthZ) 16) Pushing Left, Like a Boss — Part 5.12 — Authentication (AuthN), Identity and Access Control 17) Pushing Left, Like a Boss — Part 5.13 — HTTPS only 18) Pushing Left, Like a Boss, Part 5.14 Secure Coding Summary 19) Pushing Left, Like a Boss - Part 6: Threat Modelling 20) Pushing Left, Like a Boss - Part 7: Code Review and Static Code Analysis 21) Pushing Left, Like a Boss - Part 8: Testing 22) Pushing Left, Like a Boss - Part 9: An AppSec Program 23) Pushing Left, Like a Boss - Part 10: Special AppSec Activities and Situations

Posted on by:

Discussion

markdown guide