T09 · Insecure Skill Coding Practices
- Location
scripts/config_setup.py:65- Finding
API Credential Persisted Without Enforced Restrictive File Permissions
- Content
View full analysis
None: """ Write environment variables to .env file Args: env_vars: Dictionary of environment variables to write skill_root: Skill root directory path """ env_path = _get_env_path(skill_root) with open(env_path, "w", encoding="utf-8") as f: # Write header f.write("# GLM-OCR API Configuration\n") f.write("# Auto-generated by config_setup.py\n") f.write("# DO NOT commit this file to version control\n\n") # Write environment variables for key, value in env_vars.items(): f.write(f"{key}={value}\n") ``` ### Technical Analysis The setup process writes `ZHIPU_API_KEY` in plaintext to the project-level `.env` file. The code neither creates the file with an explicit owner-only mode nor corrects the permissions of an existing file. Consequently, the resulting permissions depend on the process umask and any permissions already assigned to the file. Under a permissive umask, the file may be readable by other local users or processes. Writing a warning inside the file does not enforce access control. The documented setup form also accepts the API key as a command-line argument: ```bash python scripts/config_setup.py setup --api-key YOUR_KEY ``` This may leave the credential in shell history and can expose it through process-argument inspection while the command is running. This exposure is related to credential provisioning, although the permission defect is specifically located in `_write_env_file()`. ### Attack Path 1. A user runs the documented setup command and supplies a valid GLM-OCR API key. 2. `config_setup.py` writes the key in plaintext to `.env` ...[truncated 1082 chars]- Remediation
View remediation
