T09 · Insecure Skill Coding Practices
Warning
- Location
- index.js:1
- Finding
- Hard-Coded Agent Token and Plaintext Transmission of Sensitive Data## Vulnerability Details **File Location**: `index.js`, lines 1–15 **Vulnerability Type**: Hard-coded credential and plaintext transmission of authentication and contact data **Risk Level**: Medium ### Vulnerable Code ```js const BACKEND_URL = "http://localhost:8001/api/v1/agent"; const AGENT_TOKEN = "sk_agent_openclaw_dev_12345"; export default { name: "telegram_analyzer", tools: { search_contacts: { description: "Search for contacts in SaaS", parameters: { type: "object", properties: { query: { type: "string" } }, required: ["query"] }, execute: async ({ query }) => { const res = await fetch(${BACKEND_URL}/search-contacts, { method: "POST", headers: { "Content-Type": "application/json", "X-Agent-Token": AGENT_TOKEN }, body: JSON.stringify({ query }) }); ``` ### Technical Analysis The skill embeds an agent authentication token directly in distributable source code. Anyone able to read the package can recover the token without needing to compromise a protected credential store. The intended request also uses unencrypted HTTP and places the token in the `X-Agent-Token` header. The request body may contain sensitive contact identifiers, names, phone numbers, or usernames supplied as search terms. Although the configured destination is `localhost`, plaintext transport still permits a malicious or compromised local service listening on port `8001` to collect both the credential and search data. The risk increases if the local service is forwarded, proxied, containerized with a shared network boundary, or accidentally exposed beyond the host. Authentication is reasonably necessary for the declared contact-search function, and transmitting a search term to the relevant backend is inherent to that operation. However, embedding a reusable credential in source code and transmitting it over plaintext HTTP exceed the minimum safe privileges and pro ...[truncated 2074 chars]
- Remediation
- ## Remediation Suggestions 1. Revoke and rotate the embedded agent token, including any identical token used in development or deployed environments. 2. Remove credentials from source code. Inject the token at runtime through a protected secret manager or narrowly scoped environment variable. 3. Assign a unique, short-lived token to each deployment and restrict it to the exact API route and operation required for contact search. 4. Replace plaintext HTTP with HTTPS using certificate validation. If the backend is strictly local, prefer authenticated operating-system IPC such as a Unix domain socket with restrictive filesystem permissions. 5. Ensure the backend binds only to the required interface and is not exposed through container port publishing, reverse proxies, or development tunnels. 6. Authenticate the backend endpoint rather than trusting `localhost`. Where appropriate, use mutual TLS, signed requests, or peer-credential validation. 7. Minimize submitted contact information, validate the `query` input, and avoid logging tokens or raw contact-search terms. 8. Correct the invalid `fetch` URL syntax only after the credential and transport controls are remediated, for example by constructing the URL through a validated URL API. 9. Add automated secret scanning and tests that reject hard-coded credentials and non-TLS endpoints before release.