T09 · Insecure Skill Coding Practices
Error
- Location
- skill.md:10
- Finding
- Bearer Credentials and Agent Communications Transmitted over Plaintext HTTP## Vulnerability Details **File Location**: `skill.md`, lines 10–11, 18, and 21 **Vulnerability Type**: Plaintext transmission of sensitive information **Risk Level**: High **Vulnerable Code Snippet**: ```markdown **Server:** `http://100.29.245.213:3456` **Skill served at:** `http://100.29.245.213:3456/skill.md` ``` ```bash python3 scripts/register.py YOUR_NAME --server http://100.29.245.213:3456 --caps "coding,fighting" --desc "Your description" ``` ```markdown Save the returned API key — all authenticated endpoints need it as `Authorization: Bearer YOUR_API_KEY`. ``` ### Technical Analysis The skill directs agents to register with and access an external service through unencrypted HTTP. It subsequently instructs them to authenticate using a bearer API key. Bearer credentials provide access based solely on possession, so transmitting them without TLS allows an attacker with network visibility to read and reuse them. Plaintext HTTP also provides no server authentication or transport integrity. An on-path attacker could impersonate the service, alter registration responses, capture newly issued API keys, modify fight submissions or messages, and inject fabricated API responses. The affected traffic includes registration data, bearer authorization headers, direct messages, channel content, profile updates, incoming fight information, and fight submissions. ### Attack Path 1. An agent follows the skill and connects to `http://100.29.245.213:3456`. 2. An attacker obtains an on-path position, such as through a compromised router, hostile wireless network, proxy, or network-level traffic interception. 3. The agent registers over HTTP and receives an API key through the unencrypted connection. 4. The attacker captures the registration response or a later `Authorization: Bearer API_KEY` request header. 5. The attacker replays the captured bearer credential against authenticated service endpoints. 6. The attacke ...[truncated 1093 chars]
- Remediation
- ## Remediation Suggestions 1. Replace every `http://` service URL with an `https://` URL protected by a valid certificate issued for a stable domain name. 2. Configure registration and authenticated clients to reject plaintext HTTP rather than silently allowing downgrade. 3. Enable strict TLS certificate and hostname verification. Do not provide insecure bypass options such as disabling certificate validation. 4. Redirecting HTTP to HTTPS is insufficient for bearer credentials; clients must initiate sensitive requests directly over HTTPS. 5. Implement short-lived, narrowly scoped access tokens and provide immediate token revocation and rotation. 6. Rotate any API keys previously transmitted through the documented HTTP endpoint because they must be treated as potentially exposed. 7. Avoid placing authorization headers or API keys in application logs, command histories, diagnostic output, or error messages. 8. Consider certificate pinning or comparable endpoint-authentication controls where the operational environment and certificate-rotation process support them. 9. Apply transport-security controls such as HTTP Strict Transport Security after migrating the service to a properly authenticated HTTPS domain. 10. Update all examples and bundled clients to use only the secured endpoint and add automated tests that fail if a plaintext service URL is configured.