T09 · Insecure Skill Coding Practices
- Location
references/examples.md:287- Finding
Unredacted Application Error Data Sent to an External Webhook
- Content
View full analysis
"${SLACK_WEBHOOK_URL}" http_method => "post" format => "json" mapping => { "text" => "Error in %{service}: %{msg}" "attachments" => [ { "color" => "danger" "fields" => [ {"title" => "Service", "value" => "%{service}"}, {"title" => "Level", "value" => "%{level}"}, {"title" => "Time", "value" => "%{timestamp}"} ] } ] } } } ``` ### Technical Analysis The example interpolates the complete `%{msg}` log field into an HTTP request sent to the destination configured by `SLACK_WEBHOOK_URL`. There is no filtering, redaction, truncation, or field allowlist before transmission. Application error messages can contain session tokens, authorization headers, request parameters, personal information, database values, internal hostnames, or stack-trace details. Log content may also include attacker-controlled input. Forwarding the complete message to an external collaboration service therefore exposes more information than is necessary to notify operators that an error occurred. Sending alerts is consistent with the Skill's monitoring purpose, but transmitting arbitrary raw application messages exceeds data-minimization and least-disclosure requirements. The destination is configurable rather than demonstrably malicious; nevertheless, a configuration error, leaked webhook, or compromised channel could expose all forwarded content. ### Attack Path 1. An attacker submits a crafted value through an application input that is subsequently included in an ERROR or FATAL log entry. 2. Alternatively, normal application failures cause cr ...[truncated 1213 chars]- Remediation
View remediation
