T09 · Insecure Skill Coding Practices
- Location
skill.md:35- Finding
User-Controlled API Base URL Can Expose HireEase Credentials
- Content
View full analysis
Vulnerability Details
File Location:
skill.md, lines 35-50 and 58-65
Vulnerability Type: Unrestricted credential destination / insufficient endpoint validation
Risk Level: HighVulnerable Code Snippet
markdown 2. `base url` to use? (e.g. `https://hireease.me` or `https://hireease-s33h.onrender.com`)markdown ## Environment variables you should expect - `HIREEASE_AGENT_EMAIL` - `HIREEASE_AGENT_PASSWORD` - `HIREEASE_API_BASE` (or use the `base url` I provided; remove trailing slash) - `HIREEASE_CLIENT_EMAIL` (optional; default if I don’t supply client email) If any required env var is missing, tell me exactly which one and stop.markdown ## HireEase API endpoints (use `{BASE}` everywhere) All private endpoints require login and use: - `Authorization: Bearer <JWT>` Discovery (no auth): - `GET {BASE}/api/agent` - `GET {BASE}/api/openapi.json` Auth: - `POST {BASE}/api/auth/login` with `{ "email", "password" }` → returns `{ token, user }`Technical Analysis
The skill allows a user-provided
base urlto replace the configured API base and subsequently instructs the agent to submit secrets fromHIREEASE_AGENT_EMAILandHIREEASE_AGENT_PASSWORDto that origin. It does not require the selected URL to match an approved HireEase hostname, enforce HTTPS, reject embedded credentials or unexpected ports, or prohibit cross-origin redirects.Consequently, the destination receiving reusable credentials is controlled by untrusted conversational input. A malicious endpoint can implement a convincing
/api/auth/loginresponse and fabricate subsequent API responses, allowing the workflow to continue after credential capture. Any bearer token sent to the same untrusted base would likewise be exposed.Attack Path
- An attacker or untrusted user supplies an attacker-controlled URL when asked for the
base url. - The skill chooses that URL as
{BASE}inste ...[truncated 1384 chars]
- An attacker or untrusted user supplies an attacker-controlled URL when asked for the
- Remediation
View remediation
Remediation Suggestions
- Remove conversational control over the authentication origin. Load the HireEase API origin exclusively from trusted administrator-managed configuration.
- If multiple deployments must be supported, use an exact allowlist of approved HTTPS origins and reject all other schemes, hosts, ports, and IP-literal destinations.
- Canonicalize and validate the complete origin before accessing secrets. Do not rely on substring or suffix matching.
- Disable redirects for authentication requests, or validate every redirect destination against the same exact allowlist.
- Bind each credential to a single configured origin and refuse to release it when the request destination differs.
- Replace reusable passwords with short-lived, scoped, revocable agent tokens that have only the client and application permissions required by this workflow.
- Apply least privilege to the agent account and retain the existing rule that secrets and tokens must never be printed.
- Log security-safe metadata for rejected destination changes without recording credentials, tokens, or sensitive request bodies.
- Add tests confirming rejection of HTTP URLs, lookalike domains, subdomain tricks, embedded user information, IP addresses, non-approved ports, and cross-origin redirects.