T09 · Insecure Skill Coding Practices
- Location
src/index.js:5- Finding
Arbitrary API Endpoint Can Receive the OpenRouter Credential and User Prompts
- Content
View full analysis
Vulnerability Details
File Location:
src/index.js, lines 5–23
Vulnerability Type: Unrestricted transmission of sensitive information to a configurable endpoint
Risk Level: HighVulnerable Code
js // 使用 OpenRouter 免费模型或其他免费 API const API_URL = process.env.OPENROUTER_API_URL || 'https://openrouter.ai/api/v1/chat/completions'; const API_KEY = process.env.OPENROUTER_API_KEY; async function chat(prompt, model = 'meta-llama/llama-4-maverick:free') { if (!API_KEY) { console.error('Error: 请设置 OPENROUTER_API_KEY 环境变量'); process.exit(1); } const res = await fetch(API_URL, { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${API_KEY}`, 'HTTP-Referer': 'https://github.com/leic8959/gpt5.5free', 'X-Title': 'gpt5.5free' }, body: JSON.stringify({ model, messages: [{ role: 'user', content: prompt }] }) });Technical Analysis
The application accepts
OPENROUTER_API_URLas an unrestricted destination and sends the value ofOPENROUTER_API_KEYin theAuthorizationheader to that destination. The complete user prompt is also included in the request body.Sending the credential and prompt to the default OpenRouter API is necessary for the declared chat functionality. However, the implementation does not validate the custom endpoint's scheme, hostname, port, or trust relationship. Consequently, an arbitrary server selected through the environment receives a credential specifically described as an OpenRouter API key.
The custom endpoint feature is documented as support for compatible providers, so the code does not establish intentional exfiltration. Nevertheless, automatically forwarding the OpenRouter credential to any configured URL exceeds the minimum safe privilege boundary. It also creates a limited server-side request forgery surface because internal URLs can be sel ...[truncated 1488 chars]
- Remediation
View remediation
Remediation Suggestions
- Restrict destinations to an explicit allowlist of trusted HTTPS hostnames, including exact hostname checks after parsing with
new URL(). - Reject non-HTTPS schemes, embedded URL credentials, unexpected ports, loopback addresses, link-local addresses, and private-network destinations unless they are explicitly required and trusted.
- Do not automatically send
OPENROUTER_API_KEYto custom providers. Use separate provider-specific credential variables or require the caller to supply authorization explicitly for a custom endpoint. - Bind credentials to providers. For example, send
OPENROUTER_API_KEYonly when the normalized hostname is the approved OpenRouter hostname. - Fail closed when endpoint validation fails, and avoid silently falling back to a destination that may receive sensitive information.
- Clearly warn users that prompts are transmitted to the selected external provider and may be processed or retained under that provider's policies.
- Add automated tests covering malicious hosts, HTTP URLs, embedded credentials, redirects, private IP ranges, and hostname-confusion cases.
- Consider disabling redirects or validating every redirect destination so an approved endpoint cannot redirect authorization-bearing requests to an untrusted host.
- Restrict destinations to an explicit allowlist of trusted HTTPS hostnames, including exact hostname checks after parsing with