T09 · Insecure Skill Coding Practices
Error
- Location
- tools/websearchapi/config.json:1
- Finding
- Plaintext Hard-Coded SearchAPI Credential## Vulnerability Details **File Location**: `tools/websearchapi/config.json:1` **Vulnerability Type**: Hard-coded secret / plaintext credential exposure **Risk Level**: High ### Vulnerable Code ```json {"apiKey":"rEux5Wb3fyHM47TKyCpNdHGf","num":5,"lang":"zh-CN","gl":"cn","engine":"google","maxRetries":3,"timeout":15000} ``` Related credential-loading and transmission logic appears in `tools/websearchapi/websearchapi.js`: ```javascript const CONFIG_FILE = path.join(__dirname, 'config.json'); function loadConfig() { try { if (fs.existsSync(CONFIG_FILE)) { return { ...DEFAULT_CONFIG, ...JSON.parse(fs.readFileSync(CONFIG_FILE, 'utf8')) }; } } catch (e) { console.error('加载配置失败:', e.message); } return DEFAULT_CONFIG; } const params = { q: query, num: options.num || config.num, hl: options.lang || config.lang, gl: options.gl || config.gl, engine: engine, api_key: config.apiKey }; const url = `${API_BASE}?${querystring.stringify(params)}`; ``` ### Technical Analysis The project distributes a reusable SearchAPI credential directly in a plaintext configuration file. Anyone who can access the source tree, a copied project archive, deployment artifact, backup, or repository history can recover the credential without authentication. The application reads this value and includes it in the HTTPS request query string. TLS protects the request in transit, but query-string credentials may still be exposed through application diagnostics, proxy logs, request traces, or URL logging. The `saveConfig()` implementation also writes configuration with `fs.writeFileSync()` without explicitly enforcing restrictive file permissions. Masking the key when the `config` command displays it does not mitigate direct access to `config.json`. ### Attack Path 1. An attacker obtains read access to the project package, repository, deployment artifact, backup, or copied tool direc ...[truncated 1045 chars]
- Remediation
- ## Remediation Suggestions 1. Immediately revoke and rotate the exposed SearchAPI key. 2. Remove the credential from the current project and repository history. Treat all existing copies as compromised. 3. Replace the committed value with an empty placeholder or example configuration. 4. Load the key from an environment variable or managed secret store, for example: ```javascript const apiKey = process.env.SEARCHAPI_API_KEY; ``` 5. Add `config.json` to `.gitignore` if it must contain local secrets, and provide a non-sensitive `config.example.json`. 6. If local file-based secret storage is unavoidable, create or update the file with owner-only permissions such as mode `0600`, and validate existing permissions before use. 7. Prefer an authorization header instead of a query parameter if the provider supports it, reducing exposure through URL logs and request traces. 8. Apply provider-side restrictions where available, including quota limits, usage alerts, endpoint restrictions, and key rotation procedures. 9. Add automated secret scanning to source-control and release pipelines to prevent future credential commits.
