T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:8
- Finding
- Hard-Coded Bearer Token Exposes Privileged Android Component Proxy<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:8-9` **Vulnerability Type**: Hard-coded authentication credential **Risk Level**: High ### Vulnerable Code ```yaml config: token: "43b618ce5f3a46c78fbde7e6eb6bcac3" baseUrl: "http://127.0.0.1:8726" ``` ### Technical Analysis The Skill embeds a concrete bearer token directly in distributable configuration. Any local user, application, or agent that can read the Skill package can recover this credential and use it to authenticate to the OSkillProxy HTTP API. The proxy exposes security-sensitive Android operations, including starting Activities and Services, sending Broadcasts, and querying, inserting, updating, deleting, or invoking ContentProviders. Consequently, possession of the token may permit a caller to perform operations under the proxy application's Android identity. Binding the service to `127.0.0.1` reduces direct remote exposure but does not protect against untrusted local processes, applications capable of accessing the loopback interface, or other agents operating in the same environment. The practical scope depends on whether the token remains active, the proxy application's granted permissions, Android component export rules, and ContentProvider access controls. ### Attack Path 1. An attacker obtains read access to the installed or distributed `SKILL.md`. 2. The attacker extracts the hard-coded token `43b618ce5f3a46c78fbde7e6eb6bcac3`. 3. The attacker checks whether the proxy is available at `http://127.0.0.1:8726`. 4. The attacker sends requests to privileged component endpoints with the extracted token in the `Authorization: Bearer` header. 5. Depending on the proxy application's permissions, the attacker starts Android components, sends broadcasts, reads provider data, invokes provider methods, or modifies and deletes provider records. ### Impact Assessment Successful exploitation can grant unauthorized access to the Android operations and data available to the prox ...[truncated 680 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove the concrete token from `SKILL.md` and all distributable source files. 2. Immediately rotate or revoke the exposed token because it must be treated as compromised. 3. Generate a unique, cryptographically secure credential for each installation rather than sharing a static project-level token. 4. Store the credential in Android Keystore or another operating-system-protected secret store and inject it only at runtime. 5. Prevent the token from appearing in logs, command histories, diagnostics, examples, or error responses. 6. Apply least privilege by restricting permitted packages, component classes, Intent actions, ContentProvider authorities, URIs, columns, and callable methods. 7. Require explicit user confirmation for destructive or sensitive actions, especially provider updates, deletions, calls, and service starts. 8. Add token expiration, rotation, revocation, and failed-authentication rate limiting. 9. Where feasible, authenticate callers using an operating-system-backed identity or local IPC mechanism instead of relying solely on a reusable bearer token over HTTP. 10. Add audit logging for authenticated operations while redacting credentials and sensitive provider content. ]]>