T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/enterprise_list.py:38
- Finding
- API Credentials May Be Exposed Through Command-Line Arguments and Plaintext Files<![CDATA[ ## Vulnerability Details **File Location**: `scripts/enterprise_list.py:38-51, 163-164` **Additional Documentation Location**: `SKILL.md:36-39` **Vulnerability Type**: Insecure credential handling **Risk Level**: Medium ### Vulnerable Code ```python def load_api_key(cli_key: str = None) -> str: """Load the API key according to the configured priority.""" if cli_key: return cli_key env_key = os.environ.get("JUHE_ENTERPRISE_LIST_KEY", "").strip() if env_key: return env_key env_file = Path(__file__).parent / ".env" if env_file.exists(): for line in env_file.read_text(encoding="utf-8").splitlines(): line = line.strip() if line.startswith("JUHE_ENTERPRISE_LIST_KEY="): val = line.split("=", 1)[1].strip().strip('"').strip("'") if val: return val return "" ``` ```python if args[i] == "--key" and i + 1 < len(args): cli_key = args[i + 1] i += 2 ``` The documentation explicitly supports both command-line and plaintext-file credential configuration: ```bash echo "JUHE_ENTERPRISE_LIST_KEY=<AppKey>" > scripts/.env python scripts/enterprise_list.py --key <AppKey> --keyword <enterprise-name> ``` ### Technical Analysis The script accepts the Juhe API key directly through the `--key` command-line argument. Command-line arguments can be observable through process-inspection facilities, monitoring agents, debugging tools, job metadata, shell history, and automation logs. Any local user or service with sufficient process visibility may capture the credential while the command is running or retrieve it from retained execution records. The script also reads the API key from an unencrypted `scripts/.env` file without checking file ownership or permissions. If that file is group-readable, world-readable, included in an archive, or accidentally committed to source control, the credential may be disclosed. The credential is legiti ...[truncated 1789 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove support for supplying API keys through `--key`, or clearly deprecate it and reject command-line credential values in normal operation. 2. Prefer a protected environment variable populated by the runtime's secret-management facility rather than by an interactive shell command that may be recorded. 3. For CI or agent deployments, retrieve the key from a dedicated secret manager and inject it only into the process environment at execution time. 4. If `.env` support must remain: - Require restrictive permissions such as mode `0600`. - Verify that the file is owned by the current user. - Reject files writable or readable by unauthorized users. - Add `scripts/.env` and other secret-bearing files to `.gitignore`. - Document that the file must never be committed, archived, or shared. 5. Update all examples to use placeholders and avoid encouraging commands that place real credentials in shell history. 6. Provide key-rotation guidance for users who may already have supplied credentials through command-line arguments or committed a `.env` file. 7. Ensure error messages, logs, telemetry, and exception reporting never include the API key or the encoded request body. ]]>
