T09 · Insecure Skill Coding Practices
- Location
main.py:236- Finding
Authentication Tokens and Session Cookies Are Persisted in Plaintext
- Content
View full analysis
Vulnerability Details
File Location:
main.py:236-242
Vulnerability Type: Plaintext storage of authentication credentials
Risk Level: MediumVulnerable Code:
python def _save_token(self) -> None: """保存 token 到配置文件""" config = load_config() config["token"] = self.token config["user_id"] = self.user_id config["saved_cookie"] = self.cookies save_config(config)The destination function at
main.py:114-118writes the resulting configuration without setting restrictive permissions:python def save_config(config: Dict) -> None: """保存配置文件""" with open(CONFIG_FILE, "w", encoding="utf-8") as f: json.dump(config, f, indent=2, ensure_ascii=False)Technical Analysis
After a successful COROS login, the Skill stores the access token, user identifier, and complete authenticated cookie string in
config.json. These values are written as unencrypted JSON. The file is opened using the process's default creation permissions, which depend on the ambient umask; the implementation neither enforces owner-only permissions nor checks the permissions of an existing file.Access tokens and session cookies are bearer credentials. An attacker generally does not need the original account password if a valid token or cookie can be replayed. Although persistence supports the declared token-caching feature, retaining the full cookie and token in a general configuration file exceeds the safest minimum required for session management.
Attack Path
- A user runs the Skill in non-demo mode and successfully authenticates to COROS.
_save_token()adds the access token and authenticated cookies toconfig.json.- The file becomes accessible through permissive local file permissions, backups, filesystem synchronization, diagnostics, or accidental repository publication.
- An attacker extracts
tokenorsaved_cookie. - The attacker replays the b ...[truncated 769 chars]
- Remediation
View remediation
Remediation Suggestions
- Store access tokens and session cookies in an operating-system keyring, credential vault, or platform-provided secret manager rather than
config.json. - If file-based storage is unavoidable, create a separate credential file atomically with owner-only permissions such as mode
0600. - Validate and repair permissions before reading or updating an existing credential file.
- Store only the minimum cookie values required for authentication rather than the complete cookie header.
- Avoid retaining both a token and redundant token-bearing cookie unless the COROS API requires both.
- Exclude credential files from source control, package uploads, backups, logs, and diagnostic bundles.
- Document how users can revoke cached sessions and provide a command to remove locally persisted credentials securely.
- Consider using short-lived tokens and refreshing them through an explicit, narrowly scoped authentication flow.
- Store access tokens and session cookies in an operating-system keyring, credential vault, or platform-provided secret manager rather than