T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/gateway-watchdog.sh:132
- Finding
- Unredacted Gateway Log Lines May Be Transmitted Through External Notification Channels<![CDATA[ ## Vulnerability Details **File Location**: `scripts/gateway-watchdog.sh:132-139`, `scripts/gateway-watchdog.sh:194-195`, `scripts/gateway-watchdog.sh:224-225`; notification workflow documented at `SKILL.md:51-56` **Vulnerability Type**: Sensitive information exposure through insufficient log redaction **Risk Level**: Medium ### Vulnerable Code ```bash get_top_errors() { local logs="$1" [ -z "$logs" ] && return printf '%s' "$logs" | grep -iE "$ERROR_PATTERNS" | \ sed -E 's/[0-9]{4}-[0-9]{2}-[0-9]{2}T[^ ]*//' | \ sed -E 's/^[^:]+: //' | \ sort | uniq -c | sort -rn | head -5 } ``` The raw error samples are added to alert output at the following call sites: ```bash echo "Top errors:" get_top_errors "$logs" ``` The documented cron workflow instructs OpenClaw to transmit the generated report through the most recently used channel: ```bash openclaw cron add \ --name "gateway-watchdog" \ --schedule "*/30 * * * *" \ --task "Run gateway-watchdog.sh verbose. If errors detected, notify user with the report." \ --channel last ``` ### Technical Analysis The watchdog reads Gateway logs and includes up to five matching log lines in its `Top errors` output. Its two `sed` transformations remove only a timestamp and a leading prefix. They do not redact bearer tokens, API keys, authorization headers, signed URLs, request parameters, message content, phone numbers, user identifiers, or other sensitive values that may appear on the same line as an error. The shell script does not directly perform an outbound network request. However, the Skill's documented end-to-end workflow directs OpenClaw to send the report through `--channel last`. Consequently, sensitive values extracted from local logs may be transmitted through Telegram, Slack, Discord, or another configured external messaging provider. Raw log samples are not required to provide the declared health-monitoring functionality. Error categories, counts, rates, and spike indicators ...[truncated 2298 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove raw log samples from notification output by default. Report only aggregate counts, rates, categories, concentration, and spike information. 2. If diagnostic samples are required, make them an explicit opt-in mode that is disabled for scheduled notifications. 3. Redact sensitive data before output using a defense-in-depth pipeline covering: - `Authorization` and `Proxy-Authorization` headers - Bearer tokens, API keys, cookies, and session identifiers - URL query parameters and signed URLs - Email addresses, phone numbers, channel identifiers, and user IDs - Message bodies and request or response payloads 4. Prefer structured log parsing with an allowlist of safe fields over regular-expression removal from complete raw lines. Only emit known-safe values such as an error code and normalized error class. 5. Truncate diagnostic samples and replace variable values with stable hashes where correlation is necessary. 6. Do not use `--channel last` for security alerts. Require an explicitly configured administrative destination and document who can receive reports. 7. Separate local verbose diagnostics from remotely deliverable alert output. For example, retain a local-only diagnostic mode while ensuring scheduled alert mode contains aggregate data only. 8. Update the `SKILL.md` Security section to disclose that optional integrations may transmit reports externally and that Gateway logs can contain sensitive information. 9. Add automated tests containing representative bearer tokens, API keys, signed URLs, phone numbers, and message content to verify that none appear in notification-safe output. ]]>