The document discusses secure coding practices for error handling and logging. It recommends avoiding information disclosure by not including sensitive details in error responses. Errors should be handled securely by returning the system to a proper state. Logs should contain important metadata like timestamps and IP addresses, and restrict access to authorized individuals only. Logs should be stored securely and prevent tampering to ensure integrity for auditing purposes. Contextual logging and cryptographic signatures can help achieve log integrity.

1. SECURE CODE
TRAINING
Error Handling and Logging
DAVID CERVIGNI
IT SECURITY CONSULTANT AND
PCI CODE REVIEWER

2. Bad Error Handling Risks
• Information disclosure
• Lack of Availability (DoS)
• Unhandled status leads to malicious behavior being
unnoticed
INSTEAD:
– Not Just catching exception
– Not Just logging exception/errors
Handle all failures securely and return the system to a proper
state!

3. Avoid information disclosure…
• Do not disclose sensitive information in error
responses, including system details, session
identifiers or account information
• Use error handlers that do not display debugging
or stack trace information
• Implement generic error messages and use
custom error pages

4. …and fail safely
• The application should handle application
errors and not rely on the server configuration
• Properly free allocated memory(resources)
when error conditions occur
• Error handling logic associated with security
controls should deny access by default

5. Server Error pages
web.xml:
<error-page> <error-code>500</error-code> <location>/app/error</location>
</error-page>
<error-page> <exception-type>java.lang.Exception</exception-type>
<location>/app/error</location> </error-page>
<error-page> <error-code>400</error-code>
<location>/index.jsp</location>
</error-page>
<error-page> <error-code>403</error-code>
<location>/app/403</location>
</error-page>
May be never enough: one solution is to configure WAF/reverse proxy
interceptor.

6. Stacktraces monsters

7. ERR00-J. Do not suppress or ignore checked
exceptions
NON COMPLIANT
COMPLIANT

8. LOGS
Checklist & Examples

9. Why we log?
Many industries are required by legal and regulatory requirements to be:
• Auditable – all activities that affect user state or balances are formally
tracked
• Traceable – it’s possible to determine where an activity occurs in all tiers
of the application
• High integrity – logs cannot be overwritten or tampered with by local or
remote users
Well-written applications will dual-purpose logs and activity traces for audit
and monitoring, and make it easy to track a transaction without excessive
effort or access to the system. They should possess the ability to easily track
or identify potential fraud or anomalies end-to-end.

10. Proper logging checklist
• All logging controls should be implemented on a trusted system (e.g., The server)
• Logging controls should support both success and failure of specified security events
• Ensure logs contain important log event data: Log Event Data, This should include the following:
– 1. Time stamp from a trusted system component
– 2. Severity rating for each event
– 3. Tagging of security relevant events, if they are mixed with other log entries
– 4. Identity of the account/user that caused the event
– 5. Source IP address associated with the request
– 6. Event outcome (success or failure)
– 7. Description of the event
• Restrict access to logs to only authorized individuals
• Utilize a master routine for all logging operations
• Do not store sensitive information in logs, including unnecessary system details, session identifiers
or passwords
• Ensure that a mechanism exists to conduct log analysis

11. Proper logging checklist
• Log all input validation failures
• Log all authentication attempts, especially failures
• Log all access control failures
• Log all apparent tampering events, including unexpected changes to state
data
• Log attempts to connect with invalid or expired session tokens
• Log all system exceptions
• Log all administrative functions, including changes to the security
configuration settings
• Log all backend TLS connection failures
• Log cryptographic module failures

12. Log forging
Log forging vulnerabilities occur when:
• Data enters an application from an untrusted source.
• The data is written to an application or system log file.

13. Log forging
If a user submits the string "twenty-one" for val, the following entry is logged:
INFO: Failed to parse val=twenty-one
However, if an attacker submits the string
"twenty-one%0a%0aINFO:+User+logged+out%3dbadguy",
the following entry is logged:
INFO: Failed to parse val=twenty-one
INFO: User logged out=badguy

14. Log injection & blind XSS example
• Impacting through downstream systems (log monitoring, analysis, feeds)

15. Contextual logging libraries
• Log4j MDC (Mapped Diagnostic Context)
• Is part of Log4j 2 API

16. Log correlation and aggregation
• WAF/PROXY/LB/WEBAPP/DB

17. Cryptographic log integrity
Audit trails are legally protected in many countries, and should be
logged into high integrity destinations to prevent casual and motivated
tampering and destruction.
How to determine if you are vulnerable
• Do the logs transit in the clear between the logging host and the
destination?
• Do the logs have a HMAC or similar tamper proofing mechanism to
prevent change from the time of the logging activity to when it is
reviewed?
• Can relevant logs be easily extracted in a legally sound fashion to
assist with prosecutions?

18. SECURE CODE
TRAINING
INTENSIVE COURSE
DAVID CERVIGNI
IT SECURITY CONSULTANT AND
PCI CODE REVIEWER
References:
https://www.owasp.org/index.php/Log_Injection
https://www.securecoding.cert.org/confluence/pages/viewp
age.action?pageId=18581047
https://logging.apache.org/log4j/2.x/manual/thread-
context.html
https://www.owasp.org/index.php/Error_Handling,_Auditing
_and_Logging
https://www.loggly.com/ultimate-guide/java-logging-basics/