T09 · Insecure Skill Coding Practices
Error
- Location
SKILL.md:268- Finding
Bearer Authentication Token Exposed Through Raw Response Logging
- Content
View full analysis
` on `GET /v1/challenge` and `POST /v1/submit` when auth is enabled. - Build sign/verify JSON with `jq --arg` — never use manual string interpolation of the multi-line message. - Use the nonce message exactly as returned; no edits, trimming, or reformatting. - Do not reuse an auth nonce — each handshake gets a fresh nonce from `/v1/auth/nonce`. - Log raw HTTP status and response body for `/v1/auth/nonce`, `/v1/auth/verify`, and `/v1/challenge` to classify failures quickly. ``` The authentication flow stores the token directly from the verification response: ```bash VERIFY_RESPONSE=$(curl -s -X POST "${COORDINATOR_URL:-https://coordinator.agentmoney.net}/v1/auth/verify" \ -H "Content-Type: application/json" \ -d "...") TOKEN=$(echo "$VERIFY_RESPONSE" | jq -r '.token') ``` ### Technical Analysis The Skill instructs the Agent to log the complete response body returned by `/v1/auth/verify`. That response contains the reusable bearer token later placed in the `Authorization` header for challenge and submission requests. Consequently, the token can be copied into terminal transcripts, CI logs, shell diagnostics, Agent telemetry, centralized logging systems, or other storage with a broader audience and longer retention period than the token itself requires. The instruction conflicts with least-privilege credential handling because troubleshooting only requires status codes and sanitized error fields, n ...[truncated 1359 chars]- Remediation
View remediation