Logging
1. Introduction:
Logging is an important asset of the security of an application architecture, since it can be used to detect flaws in applications (users constantly trying to retrieve a file that does not really exist) as well as sustained attacks from rogue users. Logs are typically properly generated by web and other server software, however you can often find them either being missing, disabled or poorly configured.
The volume of logging has to be controlled since the act of writing messages to the log uses CPU cycles, thus writing every small detail to a log will use up more resources (CPU, network bandwidth, disk space). Couple that with the fact that the logs have to be parsed or interpreted by a tool or human in order for them to be useful, the consumer of the log could have to parse through thousands of lines to find a message of consequence.
There is a lot to talk about logging best practices and we're obviously not going to dig deep into this topic. For a comprehensive guide, you can read more about logging here, as well as in the OWASP Code Review Guide.
2. Relevance context:
Applications log messages of varying intensity and to varying sinks. Many logging APIs allow you to set the granularity of log message from a state of logging nearly all messages at level ‘trace’ or ‘debug’ to only logging the most important messages at level ‘critical’. Where the log message is written to is also a consideration, sometimes it can be written to a local file, other times to a database log table, or it could be written over a network link to a central logging server.
2.1. To-log:
Input validation failures e.g. protocol violations, unacceptable encodings, invalid parameter names and values.
Output validation failures e.g. database record set mismatch, invalid data encoding.
Authentication successes and failures.
Session management failures e.g. cookie session identification value modification.
Application errors and system events e.g. syntax and runtime errors, connectivity problems, performance issues, configuration changes, etc.
Use of higher-risk functionality e.g. network connections, addition or deletion of users, changes to privileges, use of systems administrative privileges, access by application administrators, all actions by users with administrative privileges, access to payment cardholder data, data import and export including screen-based reports, submission of user-generated content - especially file uploads, etc.
2.2. Not-to-log:
Session identification values (consider replacing with a hashed value if needed to track session specific events)
Sensitive personal data and some forms of personally identifiable information (PII)
Authentication passwords (successful or unsuccessful)
Database connection strings.
Keys (any kind).
Data of a higher security classification than the logging system is allowed to store.
2.3. Storing in file-systems:
Store or copy log data to read-only media as soon as possible.
Recommended to use a separate partition than those used by the operating system, other application files and user generated content.
Apply strict permissions concerning which users can access the directories, and the permissions of files within the directories
Do not expose logs in web-accessible locations; they should have restricted access and be configured with a plain text MIME type (not HTML)
2.4. Storing in databases:
Utilize a separate database account that is only used for writing log data and which has very restrictive database, table, function and command permissions.
Read, understand and apply the SQL injection cheat sheet. :D
3. Takeaways:
With this in mind, a developer's job when logging is to:
Store only relevant and necessary application data.
Ensure that the way of storing and handling logging is done in a way that agrees with the points enumerated above.
Follow legal and contractual obligations(privacy legislation, etc). Making sure your logging won't backfire against your company is essential.
You can find more details about this topic here:
Last updated