T09 · Insecure Skill Coding Practices
Warning
- Location
- references/authentication.md:71
- Finding
- Binance API Credentials Exposed Through Script Storage and Process Arguments<![CDATA[ ## Vulnerability Details **File Location**: `references/authentication.md`, lines 71–93 **Vulnerability Type**: Insecure credential handling **Risk Level**: Medium ### Vulnerable Code ```bash #!/bin/bash API_KEY="your_api_key" SECRET_KEY="your_secret_key" BASE_URL="https://api.binance.com" # Get current timestamp TIMESTAMP=$(date +%s000) # Build query string (without signature) # CRITICAL: Keep parameter order, do NOT sort QUERY="page=1&rows=20&recvWindow=60000×tamp=${TIMESTAMP}" # Generate signature SIGNATURE=$(echo -n "$QUERY" | openssl dgst -sha256 -hmac "$SECRET_KEY" | cut -d' ' -f2) # Make request curl -X GET "${BASE_URL}/sapi/v1/c2c/orderMatch/listUserOrderHistory?${QUERY}&signature=${SIGNATURE}" \ -H "X-MBX-APIKEY: ${API_KEY}" \ -H "User-Agent: binance-wallet/1.0.0 (Skill)" ``` ### Technical Analysis The executable documentation encourages users to replace `your_api_key` and `your_secret_key` with real Binance credentials directly inside a shell script. This creates two related exposure channels: 1. The credentials may remain in a plaintext script that can be accidentally committed, backed up, logged, shared, or read by another account with access to the file. 2. The secret is expanded into the arguments of the `openssl` process through `-hmac "$SECRET_KEY"`, while the API key is expanded into the arguments of the `curl` process through the `-H` option. Depending on operating-system controls, process-monitoring software, tracing configuration, audit logging, or local user privileges, these arguments may be observable while the commands execute. The generated signature does not reveal the secret by itself. Exploitation requires access to the plaintext script, process arguments, traces, or monitoring records containing the credentials. ### Attack Path 1. A user copies the documented example and replaces the placeholders with a genuine Binance API key and secret. 2. The resulting script stores both credentials in plaintext. 3 ...[truncated 1137 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Do not instruct users to place real credentials directly in a reusable script. Load credentials at runtime from a protected secret manager or secure credential provider. 2. Avoid passing secret key material as a command-line argument. Use a signing implementation that receives the key through a protected input channel or directly through an in-process cryptographic API. 3. Avoid passing the API key through command-line header arguments where the platform may expose process arguments. Prefer an HTTP client library that constructs headers inside the process. 4. If environment variables are supported, document that they are an injection mechanism rather than durable storage and warn that privileged processes may still inspect them. 5. Ensure any credential file has restrictive permissions, is excluded from version control, and is created only with explicit user consent. 6. Disable shell tracing around credential handling, avoid printing commands or environment values, and unset sensitive variables as soon as they are no longer needed. 7. Continue requiring read-only Binance permissions and recommend Binance IP allowlisting and periodic key rotation. 8. Replace the Bash example with a small Python or JavaScript example that reads credentials securely at runtime and performs HMAC signing in process without exposing the secret in child-process arguments. ]]>