Skip to content

Pensar - auto fix for Unsanitized User Input in Log Messages Enabling Log Injection#8

Open
pensarappdev[bot] wants to merge 1 commit into
mainfrom
pensar-auto-fix-aukG
Open

Pensar - auto fix for Unsanitized User Input in Log Messages Enabling Log Injection#8
pensarappdev[bot] wants to merge 1 commit into
mainfrom
pensar-auto-fix-aukG

Conversation

@pensarappdev
Copy link
Copy Markdown

@pensarappdev pensarappdev Bot commented May 7, 2025

Secured with Pensar

Security Issue Fixed (CWE-117: Log Injection via Untrusted User Input):

  • The code previously logged user input values (user and users) directly with f-strings. An attacker could supply input with newlines, control, or escape characters, resulting in log forging, misleading log output, or log parsing errors.
  • Added a static helper method Profile._safe_log_str to sanitize user-controlled input before logging. This method:
    • Escapes \n, \r, and \t to their literal string forms.
    • Truncates input strings to a reasonable length (128 characters), appending '...' if the maximum is exceeded.
    • Escapes any other non-printable/control characters as hex codes.
  • Replaced vulnerable logger calls:
    • logger.info(f"Loading {user}'s tweets from disk")logger.info(f"Loading {self._safe_log_str(user)}'s tweets from disk")
    • logger.info(f"Not on disk! scraping {users}'s tweets now") → includes both sanitized user and a sanitized comma-separated user list.
  • This ensures that dangerous characters from external input cannot interfere with log format or inject false entries.

No dependency issues were present, and only the logging vulnerability identified in the metadata was addressed. The rest of the code was unchanged and all formatting/indentation was preserved.

More Details
Type Identifier Message Severity Link
Application CWE-117 The application writes raw, attacker-controlled values (user and users) directly into log messages without any neutralisation or encoding. If an attacker supplies a string containing newline characters, ANSI escape codes, or log-format delimiters (e.g., "evilUser\n[ERROR] System failure"), they can forge or tamper with subsequent log entries. This constitutes Improper Output Neutralisation for Logs (CWE-117) and can:
• Inject spoofed log lines that mislead operators
• Hide malicious activity by overwriting or obfuscating real events
• Break downstream log parsers or SIEM pipelines
medium Link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants