T09 · Insecure Skill Coding Practices
Warning
- Location
- ollama-web-search.sh:148
- Finding
- API Key Exposed Through curl Command-Line Arguments## Vulnerability Details **File Location**: `ollama-web-search.sh:148-154` and `ollama-web-search.sh:241-247`; insecure usage is also documented in `SKILL.md:151-161` and `README.md:113-116` **Vulnerability Type**: Sensitive credential exposure through process arguments **Risk Level**: Medium ### Vulnerable Code Search request in `ollama-web-search.sh:148-154`: ```bash HTTP_CODE=$(curl -s -o "$TEMP_DIR/response.txt" -w "%{http_code}" \ --max-time "$TIMEOUT_SECONDS" \ -X POST "https://ollama.com/api/web_search" \ --header "Authorization: Bearer $OLLAMA_API_KEY" \ --header "Content-Type: application/json" \ -d "$JSON_PAYLOAD" 2>/dev/null || echo "000") ``` Fetch request in `ollama-web-search.sh:241-247`: ```bash HTTP_CODE=$(curl -s -o "$TEMP_DIR/response.txt" -w "%{http_code}" \ --max-time "$TIMEOUT_SECONDS" \ -X POST "https://ollama.com/api/web_fetch" \ --header "Authorization: Bearer $OLLAMA_API_KEY" \ --header "Content-Type: application/json" \ -d "$JSON_PAYLOAD" 2>/dev/null || echo "000") ``` The same insecure pattern is promoted in the documentation: ```bash curl -X POST "https://ollama.com/api/web_search" \ -H "Authorization: Bearer $OLLAMA_API_KEY" \ -H "Content-Type: application/json" \ -d '{"query":"what is ollama","max_results":5}' ``` ```bash curl -X POST "https://ollama.com/api/web_search" \ -H "Authorization: Bearer $OLLAMA_API_KEY" \ -d '{"query":"test"}' ``` ### Technical Analysis The shell expands `OLLAMA_API_KEY` before launching `curl`, placing the complete bearer token in the process argument vector. Depending on the operating system, process permissions, container configuration, and monitoring environment, command-line arguments may be visible through process inspection utilities, `/proc`, audit logs, endpoint monitoring, crash diagnostics, or process telemetry. The Skill legitimately needs to authenticate to Ollama and therefore m ...[truncated 1875 chars]
- Remediation
- ## Remediation Suggestions 1. Avoid expanding the API key directly into `curl` command-line arguments. 2. Provide the sensitive header through a temporary curl configuration file or another mechanism that does not expose the token in the process argument vector. 3. Create any credential-bearing temporary file with restrictive permissions and delete it immediately after use. For example: ```bash umask 077 CURL_CONFIG="$TEMP_DIR/curl.conf" { printf 'header = "Authorization: Bearer %s"\n' "$OLLAMA_API_KEY" printf 'header = "Content-Type: application/json"\n' } > "$CURL_CONFIG" HTTP_CODE=$(curl --config "$CURL_CONFIG" \ -s -o "$TEMP_DIR/response.txt" -w "%{http_code}" \ --max-time "$TIMEOUT_SECONDS" \ -X POST "https://ollama.com/api/web_search" \ -d "$JSON_PAYLOAD" 2>/dev/null || echo "000") rm -f "$CURL_CONFIG" ``` 4. Verify that the selected mechanism does not expose the secret through verbose output, shell tracing, diagnostic logs, or error messages. 5. Keep `set -x` disabled while credentials are processed and document that users must not enable shell tracing around these requests. 6. Update the examples in `SKILL.md` and `README.md` so users are not instructed to reproduce the insecure pattern. 7. Recommend narrowly scoped, short-lived API keys where supported, and provide clear key-rotation and revocation guidance.