T09 · Insecure Skill Coding Practices
- Location
scripts/auth-manager.js:156- Finding
Authentication Token Stored in Plaintext with Non-Atomic Permission Hardening
- Content
View full analysis
Vulnerability Details
File Location:
scripts/auth-manager.js:156-168
Vulnerability Type: Plaintext credential storage and insecure file creation
Risk Level: HighVulnerable Code
js saveToken(token) { try { fs.writeFileSync(this.tokenPath, token, 'utf-8') try { fs.chmodSync(this.tokenPath, 0o600) } catch (e) { // Permission hardening failure is ignored. } } catch (e) { throw e } }Technical Analysis
The application persistently stores the authentication bearer token as plaintext in
~/.wxb-auth-token. File permissions are restricted only after the file has already been created or overwritten. Initial access permissions therefore depend on the process umask, creating a window in which the token may be accessible more broadly than intended.In addition, a failure to apply mode
0600is ignored, allowing execution to continue while the credential file may retain insecure permissions. The token is not encrypted, expiration-validated, rotated, or protected through an operating-system credential store.Attack Path
- A user completes the documented QR-code authorization process.
- The application receives an authenticated bearer token.
saveToken()writes the complete token to~/.wxb-auth-tokenas plaintext.- The file is initially created according to the current process umask.
- Permission hardening may fail without stopping authorization.
- Another local process or account with access to the file copies the token.
- The attacker supplies the stolen token in the
X-Auth-Tokenheader when calling the Wangxiaobao API.
Impact Assessment
Successful exploitation exposes the authenticated user's session privileges. The token may permit access to sensitive customer profiles, recordings, transcripts, visits, tenant and project information, sales analysis, and other data available to the account. It may also authori ...[truncated 354 chars]
- Remediation
View remediation
Remediation Suggestions
- Store the token in an operating-system credential manager instead of a plaintext file.
- If file storage is unavoidable, create the file atomically with restrictive permissions from the outset, such as by using
fs.openSync(path, 'w', 0o600)followed by a controlled write. - Fail closed if secure permissions cannot be established; do not silently ignore permission errors.
- Write to a securely created temporary file and atomically rename it to prevent partially written credentials.
- Encrypt the token at rest using a key protected outside the token file.
- Validate token expiration before reuse and implement revocation and rotation.
- Avoid indefinite retention and automatically delete expired credentials.