T09 · Insecure Skill Coding Practices
- Location
src/index.ts:52- Finding
API Credential Exposed Through Verbose Configuration Logging
- Content
View full analysis
0 && !config.dryRun) { throw new ClawCompanyError( '配置验证失败', 'CONFIG_ERROR', { errors } ) } // Initialize logging logger = new Logger('ClawCompany', config.verbose ? LogLevel.DEBUG : LogLevel.INFO) logger.info('🦞 开始工作...') logger.debug('配置:', config) ``` The generated implementation contains the same vulnerable behavior at `dist/index.js:28`. ### Technical Analysis `loadConfig` copies `GLM_API_KEY` from the process environment into the `config.glmApiKey` property. When verbose mode is enabled, the application passes the entire configuration object to `logger.debug`. The logger ultimately sends all additional arguments to `console.log`, without redacting secret-bearing fields. Consequently, the API key is printed in plaintext. This violates the principle that credentials should not be included in diagnostic output, even when debug logging is explicitly enabled. Potential exposure locations include: - Interactive terminal history or captured terminal sessions - CI/CD job logs - Container logs - Centralized log aggregation platforms - Debug bundles supplied to support personnel - Process output captured by a parent application ### Attack Path 1. A valid `GLM_API_KEY` is supplied through the process environment. 2. The user, automation pipeline, or wrapper invokes the application with verbose logging enabled. 3. `loadConfig` stores the credential in `config.glmApiKey`. 4. `logger.debug('配置:', config)` serializes or displays the complete configuration object. 5. The plaintext key is retained in terminal, CI, container, or centralized log ...[truncated 544 chars]- Remediation
View remediation
