T09 · Insecure Skill Coding Practices
- Location
scripts/config.py:43- Finding
API Key Persisted in a Plaintext Working-Directory File
- Content
View full analysis
Vulnerability Details
File Location:
scripts/config.py:43-62
Vulnerability Type: Plaintext storage of sensitive credentials
Risk Level: MediumVulnerable Code
python def save_api_key_to_env(api_key: str) -> bool: """将API key保存到.env文件""" try: env_path = Path(".env") lines = [] if env_path.exists(): lines = env_path.read_text(encoding="utf-8").splitlines() found = False new_lines = [] for line in lines: if line.startswith("XBY_APIKEY="): new_lines.append(f"XBY_APIKEY={api_key}") found = True else: new_lines.append(line) if not found: new_lines.append(f"XBY_APIKEY={api_key}") env_path.write_text("\n".join(new_lines) + "\n", encoding="utf-8") os.environ["XBY_APIKEY"] = api_key return TrueTechnical Analysis
The API key is written directly into a plaintext
.envfile under the process's current working directory. The implementation does not explicitly create the file with restrictive permissions, verify existing ownership or permissions, reject symbolic links, or ensure that the destination is outside a source-controlled project.Consequently, the credential may inherit permissions affected by the process umask or an existing file's permissions. The relative path also makes the storage destination dependent on the directory from which the Skill is invoked. This can result in exposure through local file access, source-control commits, workspace backups, build artifacts, or an attacker-prepared symbolic link.
Attack Path
- An attacker gains read access to the project workspace, backup, artifact, or generated
.envfile. - Alternatively, where the attacker can prepare the working directory, the attacker places a symbolic link named
.envpointing to a file that the Skill process ...[truncated 888 chars]
- An attacker gains read access to the project workspace, backup, artifact, or generated
- Remediation
View remediation
Remediation Suggestions
- Prefer an operating-system credential manager or secret-management service instead of persistent plaintext storage.
- If file storage is unavoidable, place the credential in a dedicated per-user configuration directory rather than the current working directory.
- Create the credential file atomically with permissions restricted to the owning user, such as mode
0600on POSIX systems. - Verify that the destination is a regular file owned by the expected user and reject symbolic links before reading or writing.
- Use an atomic temporary-file-and-rename operation to avoid partial writes and race conditions.
- Add
.envto.gitignoreand relevant artifact-exclusion rules, while documenting that it must never be committed or shared. - Avoid printing, logging, or including the credential in exceptions.
- Provide key rotation and revocation guidance for users whose
.envfile may have been exposed.