T09 · Insecure Skill Coding Practices
- Location
utils.py:77- Finding
API Credential Stored Without Restrictive File Permissions
- Content
View full analysis
Vulnerability Details
File Location:
utils.py:5-7andutils.py:77-79
Vulnerability Type: Plaintext credential storage with permissions inherited from the process environment
Risk Level: MediumVulnerable Code
python JIUMA_API_KEY_SAVE_DIR = f"{os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__))))}/.jiuma" os.makedirs(JIUMA_API_KEY_SAVE_DIR, exist_ok=True) JIUMA_API_KEY_SAVE_PATH = f"{JIUMA_API_KEY_SAVE_DIR}/jiuma_api_key"python def save_jiuma_api_key(api_key): with open(JIUMA_API_KEY_SAVE_PATH, "w") as f: f.write(api_key)Technical Analysis
The API secret returned after authentication is written directly to a plaintext file. Neither the directory nor the credential file is created with an explicit restrictive mode. Their resulting permissions therefore depend on the process umask and preexisting filesystem state.
The implementation also does not verify that the destination is a regular file owned by the current user. In an environment where another local principal can manipulate the parent directory, a pre-created file or symbolic link may redirect or expose the credential.
Persistent local storage is reasonably necessary for the documented authenticated API workflow, but broadly readable plaintext storage is not required and exceeds minimum safe access. This finding does not establish remote credential exfiltration; exploitation requires relevant local filesystem access or an insecure deployment configuration.
Attack Path
- A user completes the Jiuma login flow.
login.pyreceives asecret_keyfrom the remote service and callssave_jiuma_api_key.utils.pywrites the secret to.jiuma/jiuma_api_keyusing permissions derived from the current umask or existing file.- If those permissions allow another local account or process to read the file, that principal obtains the API key.
- The exposed key can then be us ...[truncated 547 chars]
- Remediation
View remediation
Remediation Suggestions
- Create the credential directory with mode
0700and verify that it is owned by the current user. - Create the credential file atomically with mode
0600, such as throughos.openwithO_CREAT | O_EXCL | O_WRONLYand an explicit mode. - Reject symbolic links and verify the final destination with
lstatbefore replacing an existing credential. - Write to a protected temporary file and atomically rename it into place.
- Prefer an operating-system credential store or secret-management service instead of a plaintext file.
- Strip unintended whitespace when reading the key and provide a secure credential deletion or rotation mechanism.
- Create the credential directory with mode
