T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/bark-send.sh:108
- Finding
- Bark Device Key Exposed Through Command-Line Arguments and Troubleshooting Output<![CDATA[ ## Vulnerability Details **File Location**: `scripts/bark-send.sh:54-57, 108, 163-170`; additional unsafe guidance at `SKILL.md:176` **Vulnerability Type**: Sensitive credential exposure **Risk Level**: Medium ### Vulnerable Code ```bash -k|--key) DEVICE_KEY="$2" shift 2 ;; ``` ```bash # Build request URL API_URL="https://api.day.app/${DEVICE_KEY}" ``` ```bash # Send request RESPONSE=$(curl -s -X POST "$FULL_URL" \ -H 'Content-Type: application/json' \ -d "$JSON_PAYLOAD" 2>&1) ``` The documentation also recommends printing the credential directly: ```bash 1. 检查 BARK_KEY 是否正确: `echo $BARK_KEY` ``` ### Technical Analysis The Bark device key acts as an authorization credential because anyone possessing it can submit push notifications for the associated Bark device. The shell implementation places this key inside `FULL_URL`, which is passed to `curl` as a command-line argument. While `curl` is running, local users or monitoring software with sufficient process visibility may be able to inspect the URL through process listings, process telemetry, shell tracing, audit logs, or debugging tools. Supplying the key through `-k` creates an additional exposure because the key is already present in the shell script's own process arguments. The troubleshooting documentation compounds the issue by recommending `echo $BARK_KEY`, which can disclose the key through terminal recording, shell-session capture, CI logs, support transcripts, or screen sharing. The request uses HTTPS, so this finding does not imply that the key is transmitted in plaintext over the network. The exposure occurs locally and in operational logs. ### Attack Path 1. A user invokes the shell script with `BARK_KEY` configured or supplies the key through `-k`. 2. The script embeds the key in `https://api.day.app/${DEVICE_KEY}`. 3. The complete URL is passed as an argument to the `curl` process. 4. A local observer, process-monitoring agent, or log collector captures ...[truncated 829 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Do not recommend printing the complete key. Replace the troubleshooting instruction with a presence check or masked diagnostic, for example: ```bash if [[ -n "${BARK_KEY:-}" ]]; then printf 'BARK_KEY is configured: %.4s...%s\n' \ "$BARK_KEY" "${BARK_KEY: -4}" else echo 'BARK_KEY is not configured' fi ``` 2. Discourage passing the key through `-k`, because command-line arguments are commonly observable. Prefer a protected environment variable, restricted configuration file, standard-input mechanism, or operating-system secret store. 3. Prefer an HTTPS client implementation in which the secret URL path is constructed inside the process rather than supplied to an external executable as an argument. The existing Node implementation avoids passing the API URL to a child process, although its `-k` option should still be deprecated for the same command-line exposure reason. 4. If the shell implementation must remain, clearly document the local process-visibility risk and ensure execution environments restrict process inspection and command logging. 5. Redact Bark keys from application logs, traces, error reports, telemetry, CI output, and support bundles. 6. Rotate the Bark device key if it has previously been printed, logged, or used through command-line arguments in an untrusted multi-user environment. ]]>