T09 · Insecure Skill Coding Practices
Note
- Location
- index.js:52
- Finding
- Raw Internal Error Disclosure## Vulnerability Details **File Location**: `index.js:52` **Vulnerability Type**: Unfiltered exception disclosure **Risk Level**: Low **Vulnerable Code**: ```javascript } catch (error) { return { success: false, message: '计费校验失败：' + error.message }; } ``` ### Technical Analysis The main entry point concatenates `error.message` directly into its caller-visible response. Exceptions may originate from the billing SDK, filesystem operations, invalid arguments, or Node.js module loading. Their messages can contain internal file paths, package and module names, service details, or upstream diagnostic information. The project also invokes `require('./excel-handler')`, while that module was absent from the audited package. If an entitled user reaches this code path, Node.js may generate a module-resolution error containing internal implementation and path information, which the catch block then returns without filtering. ### Attack Path 1. An attacker invokes `main` using an account that passes the permanent-purchase check, or supplies inputs that provoke a billing or processing exception. 2. Execution reaches `cleanExcel(fileParams.path)` or another failing SDK operation. 3. The missing handler, malformed parameters, filesystem failure, or SDK failure raises an exception. 4. The catch block reads the raw `error.message`. 5. The application returns that message to the attacker, potentially disclosing internal paths or dependency and service details. ### Impact Assessment This issue does not directly grant code execution, elevated privileges, or unauthorized data access. It can disclose implementation details useful for reconnaissance and for refining subsequent attacks. The scope is limited to diagnostic information present in exceptions generated by reachable operations.
- Remediation
- ## Remediation Suggestions - Return a generic caller-facing error such as `The request could not be completed`. - Record detailed diagnostics only in a restricted server-side logging system. - Avoid logging secrets, payment details, access tokens, or unnecessary user data. - Assign a correlation ID to each failure and return only that identifier to the caller. - Validate `userId`, `fileParams`, and `fileParams.path` before invoking SDK or file-processing operations. - Add the required `excel-handler` implementation before deployment and handle expected module and processing failures with predefined, non-sensitive messages. Example hardening: ```javascript } catch (error) { const incidentId = createIncidentId(); logger.error({ incidentId, error }, 'Excel skill execution failed'); return { success: false, message: `The request could not be completed. Reference: ${incidentId}` }; } ```