T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/generate_auth_token.py:27
- Finding
- Reusable API Credentials Exposed Through Command-Line Arguments and Standard Output<![CDATA[ ## Vulnerability Details **File Location**: `scripts/generate_auth_token.py:27-42` **Vulnerability Type**: Sensitive credential exposure **Risk Level**: Medium ### Vulnerable Code ```python credentials = f"{app_key}:{app_secret}" access_token = base64.b64encode(credentials.encode()).decode() return access_token if __name__ == "__main__": if len(sys.argv) != 3: print("Usage: python generate_auth_token.py <app_key> <app_secret>") sys.exit(1) app_key = sys.argv[1] app_secret = sys.argv[2] token = generate_access_token(app_key, app_secret) print(f"Access Token: {token}") print(f"\nUse in Authorization header as: Basic {token}") ``` The insecure invocation is also explicitly recommended in `SKILL.md:19`: ```bash python scripts/generate_auth_token.py YOUR_APP_KEY YOUR_APP_SECRET ``` ### Technical Analysis The script accepts the application secret as a command-line argument and prints a Base64 representation of `app_key:app_secret` to standard output. Base64 is an encoding mechanism, not encryption. Any party that obtains the generated token can decode it to recover both credential values or replay it directly as an HTTP Basic Authorization credential. Printing the token therefore has substantially the same security implications as printing the original secret. Passing the secret through `sys.argv` can expose it through shell history, process inspection facilities, diagnostic tooling, terminal recording, and execution logs. Printing the generated token creates additional exposure through Agent transcripts, captured standard output, CI logs, shell scrollback, and other logging systems. The client-side Base64 construction in `scripts/tomoviee_recognition_client.py:17-25` is not independently classified as a vulnerability because it constructs a standard Basic-auth header in memory and sends it over HTTPS to the fixed, documented Wondershare API. The avoidable security issue is the separate helper's disclosu ...[truncated 1645 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the standalone workflow that prints the complete Basic-auth token. Construct the Authorization header only in memory immediately before an API request. 2. Do not accept application secrets through command-line arguments. Retrieve them from a protected secret manager, restricted environment variable, or hidden interactive input using `getpass.getpass()`. 3. If a token-generation utility must remain, do not print the token by default. Pass it directly to the consuming process through a protected channel. 4. Redact credentials and Authorization headers from all logs, exceptions, Agent responses, debug output, and telemetry. 5. Update `SKILL.md` so it no longer recommends placing secrets on the command line. 6. Minimize credential lifetime in memory and avoid storing the generated token as long-lived object state where practical. 7. Rotate any credentials that have already been used with this helper in logged, shared, or Agent-observed environments. 8. Apply least-privilege service permissions, quota limits, and service-side credential rotation policies to reduce the impact of future disclosure. ]]>