GitBook: [master] 2 pages modified

SUMMARY.md

@@ -25,4 +25,5 @@
 
 * [Vulnerable Dependency Management](auxiliary/vulnerable-dependency-management.md)
 * [Deserialization](auxiliary/deserialization.md)
+* [Logging](auxiliary/logging.md)
 

auxiliary/logging.md

@@ -0,0 +1,59 @@
+# 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 %}
+