T09 · Insecure Skill Coding Practices
Error
- Location
- src/auth.js:21
- Finding
- OAuth Tokens Are Encrypted with a Public, Hard-Coded Fallback Key<![CDATA[ ## Vulnerability Details **File Location**: `src/auth.js:21-22`; `src/baidu-api.js:14-15` **Vulnerability Type**: Predictable encryption key used for credential storage **Risk Level**: High ### Vulnerable Code `src/auth.js:21-22`: ```js const ENCRYPTION_KEY = process.env.ENCRYPTION_KEY || crypto.createHash('sha256').update('baidu-netdisk-skill-secret-2026').digest('hex'); ``` `src/baidu-api.js:14-15`: ```js const ENCRYPTION_KEY = process.env.ENCRYPTION_KEY || crypto.createHash('sha256').update('baidu-netdisk-skill-secret-2026').digest('hex'); ``` The key is subsequently used to encrypt and decrypt OAuth credentials: ```js function encrypt(text) { return CryptoJS.AES.encrypt(text, ENCRYPTION_KEY).toString(); } function decrypt(ciphertext) { const bytes = CryptoJS.AES.decrypt(ciphertext, ENCRYPTION_KEY); return bytes.toString(CryptoJS.enc.Utf8); } ``` ### Technical Analysis The application encrypts OAuth access and refresh tokens with AES, but it silently falls back to a key derived from a constant embedded in the public source code. Every installation that does not explicitly set `ENCRYPTION_KEY` therefore uses the same reproducible key. Encryption does not provide confidentiality when an attacker can derive the encryption key from public information. Anyone who obtains the configuration ciphertext can reproduce the SHA-256-derived key and decrypt the stored credentials using CryptoJS or another compatible implementation. This is particularly significant for refresh tokens because they may allow an attacker to obtain new access tokens after the original access token expires. ### Attack Path 1. A user completes OAuth authorization without setting the optional `ENCRYPTION_KEY` environment variable. 2. The application encrypts the access and refresh tokens using the public fallback key. 3. An attacker, malicious local process, compromised backup service, or configuration-file recipient obtains the Skill configuration file. 4. The ...[truncated 1015 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the source-controlled fallback key entirely. Refuse to encrypt credentials unless secure key material is available. 2. Store OAuth tokens in an operating-system credential manager, such as: - macOS Keychain - Windows Credential Manager - Linux Secret Service or an equivalent protected keyring 3. If file-based encryption is unavoidable: - Generate a cryptographically random, unique key for every installation. - Protect that key independently from the encrypted configuration. - Use authenticated encryption such as AES-256-GCM. - Never store the encryption key alongside the ciphertext. 4. If a user password is used, derive the key with a password-hardening KDF such as Argon2id or scrypt using a unique random salt. 5. Add a migration routine that decrypts credentials stored with the legacy key and immediately re-encrypts or moves them into secure storage. 6. Warn users that previously encrypted configuration files should be treated as potentially exposed, and recommend revoking and rotating existing tokens. ]]>