T09 · Insecure Skill Coding Practices
Warning
- Location
scripts/api_client.js:52- Finding
Authentication Token Stored Without Explicitly Restrictive File Permissions
- Content
View full analysis
= expiresAt.getTime()) return null; return data.token || null; } catch (e) { console.error(`Warning: Failed to load token file: ${e.message}`); return null; } } async function _fetchNewToken() { const reqUrl = `${BASE_URL}/token`; const { status, body } = await _httpRequest(reqUrl); if (status === 200) { const data = JSON.parse(body); fs.writeFileSync(TOKEN_FILE, JSON.stringify(data)); return data.token; } throw new Error(`Failed to fetch token. Status: ${status}`); } ``` ### Technical Analysis The client persists the API session token in plaintext at `scripts/.token`. The call to `fs.writeFileSync` does not set an explicit restrictive file mode, so the resulting permissions depend on the host process's umask and the state of any existing file. On a permissively configured multi-user system, another local account or process may be able to read the cached token. Storing runtime credentials inside the Skill source directory also increases the possibility that the file will be copied, archived, or included in a package unintentionally. The network token is required for the declared market-data functionality, and the documentation discloses the cache. The security issue is therefore not the retrieval itself, but the insufficiently hardened storage mechanism. ### Attack Path 1. ...[truncated 1171 chars]- Remediation
View remediation