T09 · Insecure Skill Coding Practices
- Location
index.js:50- Finding
Tenant Access Token Stored in an Insufficiently Protected Plaintext Cache
- Content
View full analysis
Vulnerability Details
File Location:
index.js, lines 50-68
Vulnerability Type: Plaintext storage of a reusable bearer token
Risk Level: MediumVulnerable Code:
js async function getToken() { try { if (fs.existsSync(TOKEN_CACHE_FILE)) { const cached = JSON.parse(fs.readFileSync(TOKEN_CACHE_FILE, 'utf8')); if (cached.expire > Date.now() / 1000 + 300) return cached.token; } } catch (e) {} const res = await post('https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal', { app_id: APP_ID, app_secret: APP_SECRET }); if (!res.tenant_access_token) throw new Error(`Token fetch failed: ${JSON.stringify(res)}`); try { fs.writeFileSync(TOKEN_CACHE_FILE, JSON.stringify({ token: res.tenant_access_token, expire: Date.now() / 1000 + res.expire })); } catch (e) {}Technical Analysis
The Skill writes a reusable Feishu tenant access token as plaintext to the predictable path
../../memory/feishu_token.json. Thefs.writeFileSynccall does not specify a restrictive file mode such as0600. A newly created file therefore receives permissions derived from the process umask and may be readable by other local accounts or processes. If the file already exists, its existing permissions remain in effect.The implementation also performs separate existence and read operations and does not reject symbolic links or verify the file's owner, type, or permissions. In a locally hostile environment, an attacker with suitable access to the cache directory could potentially manipulate the predictable cache path. Silent exception handling further prevents administrators from learning that secure caching has failed.
The token is sent only to the official Feishu API, and obtaining such a token is necessary for the declared forwarding functionality. The vulnerability is the unnecessary persistence of that credential withou ...[truncated 1305 chars]
- Remediation
View remediation
Remediation Suggestions
- Avoid persistent token caching if obtaining a fresh short-lived token for each invocation is operationally acceptable.
- If caching is required, create a dedicated private directory that is owned by the service account and has mode
0700. - Create or replace the token file atomically with mode
0600; do not rely solely on the ambient process umask. - Reject symbolic links and verify that the cache is a regular file owned by the expected account before reading it.
- Use secure open flags such as exclusive creation and no-follow behavior where supported, then write through the validated file descriptor.
- Consider a platform credential store or secrets manager instead of a plaintext filesystem cache.
- Apply the minimum required Feishu application scopes and periodically review them so compromise of the token has limited impact.
- Log cache security failures without including the token, application secret, or complete authentication response.
- Remove expired cache files securely and rotate credentials after suspected exposure.