Skip to content
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
146 changes: 146 additions & 0 deletions docs/Secure-Coding-Guide-for-Python/CWE-707/CWE-117/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,146 @@
# CWE-117: Improper Output Neutralization for Logs

Log injection occurs when untrusted data is written to application logs without proper neutralization, allowing attackers to forge log entries or inject malicious content. Attackers can inject fake log records or hide real ones by inserting newline sequences (`\r` or `\n`), misleading auditors and incident-response teams. This vulnerability can also enable injection of XSS attacks when logs are viewed in vulnerable web applications.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the first sentence here works as the introductory sentence in the first paragraph.


Attackers can exploit this weakness by submitting strings containing CRLF (Carriage Return Line Feed) sequences that create fake log entries. For instance, an attacker authenticating with a crafted username can make failed login attempts appear successful in audit logs, potentially framing innocent users or hiding malicious activity.

This vulnerability is classified as **CWE-117: Improper Output Neutralization for Logs** [cwe117]. It occurs when CRLF sequences are not properly neutralized in log output, which is a specific instance of the broader **CWE-93: Improper Neutralization of CRLF Sequences** [cwe93] weakness. Attackers exploit this using the **CAPEC-93: Log Injection-Tampering-Forging** [capec93] attack pattern.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this type of relation is already covered (but not explained) in 'related guidelines'. It gets difficult to know what to list as reference vs related guidelines if guidelines are this heavily listed as an argument in the body. We typically do not explain these relations unless the explianation is required to understand the content of the rule.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, my thinking was that because this this is so similar to CWE-93, and because the example of CRLF in logs is actually the second example for https://cwe.mitre.org/data/definitions/93.html (so the example given here also covers CWE-93) that it was worth clarifying the relationship. I don't object to removing the second paragraph if you'd prefer that.


The OWASP Top 10 lists “Security Logging and Monitoring Failures” as a critical security risk, emphasizing that log data must be encoded correctly to prevent injections.

## Noncompliant Code Example

This example demonstrates how raw user input written to logs enables injection attacks:

```python
""" Non-compliant Code Example """
import logging

def log_authentication_failed(user):
"""Simplified audit logging missing RFC 5424 details"""
logging.warning("User login failed for: '%s'", user)

#####################
# attempting to exploit above code example
#####################
log_authentication_failed("guest'\nWARNING:root:User login failed for: 'administrator")
```

The output demonstrates successful log injection:

```bash
WARNING:root:User login failed for: 'guest'
WARNING:root:User login failed for: 'administrator'
```

The attacker's input creates what appears to be a legitimate log entry showing a login failure for user `administrator`.

## Compliant Solution

The `compliant01.py` solution uses a strict allow-list for usernames and returns early on any mismatch, so CR/LF or other disallowed characters never reach the logger; for rejected attempts it logs a safe one-line summary with `%r` (escaped newlines), preventing forged secondary log lines. In short: validate upfront and neutralize what you do record.

```python
""" Compliant Code Example """

import logging
import re

# Allow only ASCII letters, digits, underscore, dot, and hyphen; max 64 chars
_ALLOWED_USER = re.compile(r"^[A-Za-z0-9._-]{1,64}$")


def is_allowed_username(user: str) -> bool:
"""Return True if username matches the strict allow-list."""
return bool(_ALLOWED_USER.fullmatch(user))


def log_authentication_failed(user):
"""Simplified audit logging (example)"""
if not is_allowed_username(user):
# Safe summary: %r escapes CR/LF so the log remains one line
logging.warning("Rejected login attempt: invalid username=%r", user)
return
logging.warning("User login failed for: '%s'", user)


#####################
# attempting to exploit above code example
#####################
log_authentication_failed("guest'\nWARNING:root:User login failed for: 'administrator")



# TODO: Production — keep sink-side neutralization (escape CR/LF) even with validation,
# prefer structured JSON logs.
```

The following output shows that a warning is logged, and the input is sanitized before logging.

```bash
WARNING:root:Rejected login attempt: invalid username="guest'\nWARNING:root:User login failed for: 'administrator"
```

## Automated Detection

<table>
<thead>
<tr>
<th>Tool</th>
<th>Version</th>
<th>Check</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>Bandit</td>
<td>1.7.5</td>
<td>Not Available</td>
<td></td>
</tr>
<tr>
<td>PyLint</td>
<td>2.17</td>
<td>Not Available</td>
<td></td>
</tr>
<tr>
<td>CodeQL</td>
<td>Latest</td>
<td><a href="https://codeql.github.com/codeql-query-help/python/py-log-injection/">py-log-injection</a></td>
<td></td>
</tr>
<tr>
<td>Veracode</td>
<td>Latest</td>
<td>CWE 117</td>
<td><a href="https://community.veracode.com/s/article/How-to-Fix-CWE-117-Improper-Output-Neutralization-for-Logs">How to Fix CWE-117</a></td>
</tr>
</tbody>
</table>

## Related Guidelines

- **CWE-117**: Improper Output Neutralization for Logs [cwe117]
- **CWE-93**: Improper Neutralization of CRLF Sequences ('CRLF Injection') [cwe93]
- **CWE-113**: Improper Neutralization of CRLF Sequences in HTTP Headers [cwe113]
- **CAPEC-93**: Log Injection-Tampering-Forging [capec93]
- **OWASP Top 10 2021**: A09 - Security Logging and Monitoring Failures [owasp_top10_2021]
- **OWASP ASVS 4.0**: V7.1 Log Content Requirements [owasp_asvs]
- **ISO/IEC TR 24772:2013**: Injection [RST] [iso24772]
- **NIST SP 800-92**: Guide to Computer Security Log Management [nist80092]

## Bibliography

<ul>
<li>[cwe117] MITRE. “CWE-117: Improper Output Neutralization for Logs” [online]. Available from: <a href="https://cwe.mitre.org/data/definitions/117.html">https://cwe.mitre.org/data/definitions/117.html</a>. Accessed 23 September 2025.</li>
<li>[cwe93] MITRE. “CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')” [online]. Available from: <a href="https://cwe.mitre.org/data/definitions/93.html">https://cwe.mitre.org/data/definitions/93.html</a>. Accessed 23 September 2025.</li>
<li>[cwe113] MITRE. “CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers” [online]. Available from: <a href="https://cwe.mitre.org/data/definitions/113.html">https://cwe.mitre.org/data/definitions/113.html</a>. Accessed 23 September 2025.</li>
<li>[capec93] MITRE. “CAPEC-93: Log Injection‑Tampering‑Forging” [online]. Available from: <a href="https://capec.mitre.org/data/definitions/93.html">https://capec.mitre.org/data/definitions/93.html</a>. Accessed 23 September 2025.</li>
<li>[nist80092] Kent, K.; Souppaya, M. “NIST Special Publication 800‑92: Guide to Computer Security Log Management” [online]. Available from: <a href="https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf">https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf</a>. Accessed 23 September 2025.</li>
<li>[owasp_asvs] OWASP. “Application Security Verification Standard 4.x” [online]. Available from: <a href="https://owasp.org/www-project-application-security-verification-standard/">https://owasp.org/www-project-application-security-verification-standard/</a>. Accessed 23 September 2025.</li>
<li>[owasp_top10_2021] OWASP. “OWASP Top 10 — 2021: A09 Security Logging and Monitoring Failures” [online]. Available from: <a href="https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/">https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/</a>. Accessed 23 September 2025.</li>
<li>[codeql] GitHub. “Log Injection — CodeQL query help (Python)” [online]. Available from: <a href="https://codeql.github.com/codeql-query-help/python/py-log-injection/">https://codeql.github.com/codeql-query-help/python/py-log-injection/</a>. Accessed 23 September 2025.</li>
<li>[veracode] Veracode. “How to Fix CWE‑117 — Improper Output Neutralization for Logs” [online]. Available from: <a href="https://community.veracode.com/s/article/How-to-Fix-CWE-117-Improper-Output-Neutralization-for-Logs">https://community.veracode.com/s/article/How-to-Fix-CWE-117-Improper-Output-Neutralization-for-Logs</a>. Accessed 23 September 2025.</li>
<li>[iso24772] ISO/IEC. “TR 24772:2013 — Programming languages — Guidance to avoiding vulnerabilities in programming languages through language selection and use (Withdrawn)” [online]. Available from: <a href="https://www.iso.org/standard/61457.html">https://www.iso.org/standard/61457.html</a>. Accessed 23 September 2025.</li>
</ul>
29 changes: 18 additions & 11 deletions docs/Secure-Coding-Guide-for-Python/CWE-707/CWE-117/compliant01.py
Original file line number Diff line number Diff line change
@@ -1,26 +1,33 @@
# SPDX-FileCopyrightText: OpenSSF project contributors
# SPDX-License-Identifier: MIT
""" Compliant Code Example """
"""Compliant Code Example"""

import logging
import re

# Allow only ASCII letters, digits, underscore, dot, and hyphen; max 64 chars
_ALLOWED_USER = re.compile(r"^[A-Za-z0-9._-]{1,64}$")


def allowed_chars(user):
"""Verify only allowed characters are used"""
if bool(re.compile(r"\w+").fullmatch(user)):
return True
return False
def is_allowed_username(user: str) -> bool:
"""Return True if username matches the strict allow-list."""
return bool(_ALLOWED_USER.fullmatch(user))


def log_authentication_failed(user):
"""Simplified audit logging missing RFC 5424 details"""
if not allowed_chars(user):
logging.critical("Login attempt with non-allowed characters in user name: '%s'", user)
"""Simplified audit logging (example)"""
if not is_allowed_username(user):
# Safe summary: %r escapes CR/LF so the log remains one line
logging.warning("Rejected login attempt: invalid username=%r", user)
return
logging.warning("User login failed for: '%s'", user)


#####################
# attempting to exploit above code example
#####################
log_authentication_failed("""foo
WARNING:root:User login failed for: administrator""")
log_authentication_failed("guest'\nWARNING:root:User login failed for: 'administrator")


# TODO: Production — keep sink-side neutralization (escape CR/LF) even with validation,
# prefer structured JSON logs.
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
# SPDX-FileCopyrightText: OpenSSF project contributors
# SPDX-License-Identifier: MIT
""" Non-compliant Code Example """
"""Non-compliant Code Example"""

import logging


Expand All @@ -12,5 +13,4 @@ def log_authentication_failed(user):
#####################
# attempting to exploit above code example
#####################
log_authentication_failed("""foo
WARNING:root:User login failed for: administrator""")
log_authentication_failed("guest'\nWARNING:root:User login failed for: 'administrator")
2 changes: 1 addition & 1 deletion docs/Secure-Coding-Guide-for-Python/readme.md
Original file line number Diff line number Diff line change
Expand Up @@ -110,7 +110,7 @@ It is __not production code__ and requires code-style or python best practices t
|:----------------------------------------------------------------|:----|
|[CWE-78: Improper Neutralization of Special Elements Used in an OS Command ("OS Command Injection")](CWE-707/CWE-78/README.md)|[CVE-2024-43804](https://www.cvedetails.com/cve/CVE-2024-43804/),<br/>CVSSv3.1: __8.8__,<br/>EPSS: __00.06__ (08.11.2024)|
|[CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')](CWE-707/CWE-89/README.md)|[CVE-2019-8600](https://www.cvedetails.com/cve/CVE-2019-8600/),<br/>CVSSv3.1: __9.8__,<br/>EPSS: __01.43__ (18.02.2024)|
|[CWE-117: Improper Output Neutralization for Logs](CWE-707/CWE-117/.)||
|[CWE-117: Improper Output Neutralization for Logs](CWE-707/CWE-117/README.md)||
|[CWE-175: Improper Handling of Mixed Encoding](CWE-707/CWE-175/README.md)||
|[CWE-180: Incorrect behavior order: Validate before Canonicalize](CWE-707/CWE-180/README.md)|[CVE-2022-26136](https://www.cvedetails.com/cve/CVE-2022-26136/),<br/>CVSSv3.1: __9.8__,<br/>EPSS: __00.18__ (24.04.2025)|
|[CWE-838: Inappropriate Encoding for Output Context](CWE-707/CWE-838/README.md)||
Expand Down