T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:38
- Finding
- Externally Exposed WebSocket Service Without Documented Authentication or Transport Security<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 38-39 and 62-65 **Vulnerability Type**: Exposed network service with insufficiently documented access and transport controls **Risk Level**: High ### Vulnerable Code ```python server = CrossCommService(role='server', ip='0.0.0.0', port=9898) await server.start_server() ``` The server initialization section repeats the externally exposed configuration: ```python server = CrossCommService( role='server', ip='0.0.0.0', # Listen on all interfaces port=9898, heartbeat_interval=30, # Seconds between heartbeats heartbeat_timeout=60 # Seconds before marking offline ) ``` ### Technical Analysis The documented configuration binds the WebSocket service to `0.0.0.0`, making it reachable through every available network interface unless an external firewall prevents access. The Skill documents a client login operation and an optional `client_id`, but it does not specify credentials, cryptographic client authentication, authorization policies, TLS/WSS, certificate validation, WebSocket origin restrictions, or network access controls. A client ID is an identifier and must not be treated as proof of identity. Because the underlying `pywayne.cross_comm` implementation is not included in the audited project, the presence or absence of internal security controls cannot be verified. Nevertheless, the Skill's recommended deployment exposes the service broadly without requiring those controls. ### Attack Path 1. A user follows the documented example and starts the server on `0.0.0.0:9898`. 2. TCP port 9898 becomes reachable from another host on an exposed network. 3. An attacker connects to the WebSocket endpoint and supplies an attacker-selected or impersonated client ID. 4. If the dependency does not implement additional undocumented authentication, the attacker logs in as a client. 5. The attacker submits messages, requests client-list functionality, or initiates ...[truncated 875 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions - Bind to `127.0.0.1` by default and require an explicit opt-in to listen on external interfaces. - Require strong client authentication, such as short-lived signed tokens or mutual TLS certificates. - Authorize every operation independently, including sending messages, selecting recipients, listing clients, and transferring files. - Use TLS-protected WebSockets (`wss://`) and document certificate validation requirements. - Reject untrusted WebSocket origins where browser-based clients are supported. - Prevent client-selected identifiers from serving as authentication credentials. - Add connection, authentication, message-rate, message-size, and concurrency limits. - Place externally reachable deployments behind a firewall or authenticated reverse proxy. - Log authentication failures and security-relevant operations without recording credentials or sensitive message contents. - Update the examples so that secure network exposure is the default rather than an optional hardening step. ]]>