# 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](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html), as well as in the [OWASP Code Review Guide](https://owasp.org/www-pdf-archive/OWASP_Code_Review_Guide_v2.pdf).

## 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](https://vladtoie.gitbook.io/secure-coding/server-side/sql-injections). :D

## 3. Takeaways:

With this in mind, a developer's job when logging is to:

1. **Store only relevant and necessary** application data.
2. **Ensure that** the way of **storing and handling logging** is done in a way that agrees with the points enumerated above.
3. **Follow legal and contractual obligations**(privacy legislation, etc). Making sure your logging won't backfire against your company is essential.

{% hint style="info" %}
You can find more details about this topic here:

* [Logging \[OWASP\]](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html)
* [Application Logs: Security Best Practices](https://www.paladion.net/blogs/application-logs-security-best-practices)
  {% endhint %}