T09 · Insecure Skill Coding Practices
Warning
- Location
- skill.js:3
- Finding
- Hard-Coded Clash REST API Bearer Secret<![CDATA[ ## Vulnerability Details **File Location**: `skill.js:3-14` **Vulnerability Type**: Hard-coded authentication credential **Risk Level**: Medium ### Vulnerable Code ```javascript const secret = 'ff62c2da-1504-446b-986f-f13ba034e8a5'; const port = 61222; function request(path, method = 'GET', body = null) { return new Promise((resolve, reject) => { const options = { hostname: '127.0.0.1', port: port, path: path, method: method, headers: { 'Authorization': `Bearer ${secret}`, 'Content-Type': 'application/json' } }; ``` ### Technical Analysis The Clash REST API bearer secret is embedded directly in the distributed source code. It is automatically attached to every API request made by the skill. A source-level credential cannot remain confidential because any user, process, archive recipient, repository reader, or package consumer with access to the project can recover it. The exposure is especially significant if this credential is also present in a live Clash configuration. The code currently connects only to `127.0.0.1`, which limits direct remote exploitation by this skill. Nevertheless, the exposed credential could be reused independently if the Clash external controller is accessible through another interface, port-forwarding arrangement, local malware, or a separate network configuration. ### Attack Path 1. An attacker obtains a copy of the project, package, repository, or source archive. 2. The attacker reads the bearer secret from `skill.js:3`. 3. The attacker identifies a running Clash controller configured with the same secret. 4. The attacker reaches that controller locally or through an exposed controller interface, tunnel, proxy, or port forward. 5. The attacker submits authenticated Clash API requests using the recovered bearer secret. 6. Within the permissions offered by the Clash API, the attacker reads proxy state or modifies proxy selection and related controller-man ...[truncated 726 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the bearer secret from the source code and package history. 2. Rotate the exposed secret in the active Clash configuration. 3. Load the secret at runtime from a protected environment variable, operating-system credential store, or permission-restricted configuration file. 4. Fail closed when the secret is absent rather than using a built-in default. 5. Keep the external controller bound to `127.0.0.1` unless remote access is explicitly required. 6. If remote access is required, place the controller behind authenticated, encrypted, and network-restricted access controls. 7. Restrict access to the runtime secret according to least privilege and prevent it from being written to logs or returned in errors. 8. Add secret-scanning checks to version-control and release pipelines. ]]>