T09 · Insecure Skill Coding Practices
Warning
- Location
scripts/get_result.sh:2- Finding
Credential Exposure Through Command-Line Arguments
- Content
View full analysis
ORDER_NO="${1:?Usage: ./get_result.sh }" CREDENTIAL="${2:?Missing credential}" QUESTION="${3:-Analyze the provided data}" SERVICE_ID="${4:-http状态码查询}" API_BASE="${XIAOMENG_API_BASE:-https://xiaomeng-api.qisir.com}" echo "Getting result for order: $ORDER_NO" RESULT=$(curl -s -X POST "$API_BASE/api/getResult" \ -H "Content-Type: application/json" \ -d "{\"reqData\": {\"orderNo\": \"$ORDER_NO\", \"credential\": \"$CREDENTIAL\", \"question\": \"$QUESTION\", \"serviceId\": \"$SERVICE_ID\"}}") ``` ### Technical Analysis The result-retrieval script requires the service credential as its second positional command-line argument. Sensitive values passed this way can be exposed through: - Interactive shell history. - Process inspection utilities while the script is executing. - Process monitoring, audit, telemetry, or diagnostic systems that record command arguments. - Wrapper scripts or automation logs that record the complete command. The README also instructs users to invoke the script with the credential directly: ```bash ./scripts/get_result.sh "" "" "your requirements" ``` The credential is subsequently included in the JSON request sent to the remote result endpoint. Transmitting it to the intended HTTPS service is part of the declared workflow, but exposing it through a process argument is not necessary for that functionality. ### Attack Path 1. A user invokes `get_result.sh` with a valid credential as the second argument. 2. The complete command is retained in shell history, automation logs, or process-monitoring records, or is observed through process inspection. 3. An attack ...[truncated 994 chars]- Remediation
View remediation