T09 · Insecure Skill Coding Practices
- Location
SKILL.md:62- Finding
Sensitive authentication data exposed through command-line request bodies
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:62-64,SKILL.md:77-79, andSKILL.md:352-355
Vulnerability Type: Insecure handling of credentials and authentication tokens
Risk Level: MediumVulnerable Code
SKILL.md:62-64:bash curl -X POST "${STOCKBOOT_API_URL}/auth/login" \ -H "Content-Type: application/json" \ -d '{"username": "18680859800", "password": "abcd1234"}'SKILL.md:77-79:bash curl -X POST "${STOCKBOOT_API_URL}/auth/register" \ -H "Content-Type: application/json" \ -d '{"phone": "13800138000", "password": "test123", "confirmPassword": "test123", "code": "123456"}'SKILL.md:352-355:bash RESPONSE=$(curl -s -X POST "${STOCKBOOT_API_URL}/auth/login" \ -H "Content-Type: application/json" \ -d '{"username":"18680859800","password":"abcd1234"}') TOKEN=$(echo $RESPONSE | jq -r '.data.token')Technical Analysis
The documented authentication and registration workflows place usernames, phone numbers, passwords, password confirmations, and SMS verification codes directly in shell command text. Although the displayed values appear to be examples rather than confirmed live credentials, users following the workflow may replace them with real values.
Literal secrets in commands may be retained by shell history, terminal recording, agent execution transcripts, command auditing systems, debugging output, or process-monitoring facilities. The login response is also stored in the
RESPONSEshell variable before the bearer token is extracted, which increases the possibility that the complete authentication response will be exposed through diagnostics or logging.The service destination can be changed through
STOCKBOOT_API_URL, as documented atSKILL.md:40-44. The feature supports self-hosting, but no origin allowlist, certificate-pinning policy, redirect restriction, or destination validation is specified. If an attacker can influence t ...[truncated 1918 chars]- Remediation
View remediation
Remediation Suggestions
- Do not place passwords, SMS codes, refresh tokens, or other secrets directly in command-line arguments.
- Obtain passwords through a non-echoing interactive prompt, protected credential manager, or secret-injection mechanism that does not persist values in shell history.
- Supply sensitive request bodies through protected standard input or a permission-restricted temporary file, and securely remove any temporary material immediately afterward.
- Replace realistic example values with unmistakable placeholders such as
<PHONE_NUMBER>,<PASSWORD>, and<SMS_CODE>. - Disable shell tracing around authentication operations and redact credentials, authorization headers, login responses, access tokens, and refresh tokens from logs and agent transcripts.
- Avoid storing the complete login response in a general-purpose shell variable. Parse only the required fields through a controlled pipeline and ensure neither the response nor token is printed.
- Validate
STOCKBOOT_API_URLbefore transmitting sensitive data. Use an explicit allowlist for trusted origins, require HTTPS, verify certificates, and reject redirects to different or untrusted origins. - Store tokens only for the minimum necessary duration, apply restrictive permissions, and clear transient variables after use.
- Require an explicit final user confirmation of the brokerage account, stock symbol, buy or sell direction, quantity, price, and order type immediately before submitting any financial transaction.
- Apply server-side safeguards such as short-lived access tokens, refresh-token rotation, revocation, rate limiting, anomaly detection, and step-up authentication for high-risk trading operations.