T09 · Insecure Skill Coding Practices
- Location
scripts/ros_cli.py:168- Finding
Robot control traffic uses plaintext WebSocket transport without client-side authentication
- Content
View full analysis
Vulnerability Details
File Location:
scripts/ros_cli.py, lines 168-175
Vulnerability Type: Plaintext, unauthenticated control channel
Risk Level: High
Category: T09: Insecure Skill Coding PracticesVulnerable Code
python def ws_connect(ip, port, timeout=5.0): """Create a WebSocket connection to rosbridge.""" try: url = f"ws://{ip}:{port}" ws = websocket.create_connection(url, timeout=timeout) return ws, None except Exception as e: return None, str(e)The client always constructs a
ws://URL. It provides no option for TLS, server certificate validation, authentication credentials, or integrity protection at the application layer.The transmitted operations include topic publication, arbitrary ROS service calls, parameter modification, and action goals. These operations can control physical movement or modify robot state. Sensor responses may also include camera images, LiDAR scans, odometry, joint states, or other operationally sensitive data.
Technical Analysis
Plain WebSocket traffic provides neither confidentiality nor transport integrity. An attacker able to observe or modify traffic between this CLI and rosbridge can inspect ROS messages, alter outgoing control operations, inject protocol frames, forge responses, or terminate the connection.
Because the client does not authenticate the rosbridge endpoint, it also cannot establish that it has connected to the intended robot. Network redirection, DNS manipulation when a hostname is used, ARP spoofing, a malicious access point, or routing compromise could direct the connection to an attacker-controlled WebSocket server.
The implementation also offers no authentication mechanism for the ROS control session. Whether an independently connecting remote attacker can reach rosbridge depends on external network controls and rosbridge deployment settings, but this client does not enforce ...[truncated 1686 chars]
- Remediation
View remediation
Remediation Suggestions
- Add explicit support for
wss://and make encrypted transport the default for non-loopback destinations. - Validate the server certificate against a trusted CA and reject invalid, expired, or hostname-mismatched certificates.
- Support certificate or public-key pinning for safety-critical robot deployments.
- Add an authentication mechanism appropriate to the rosbridge deployment, such as mutually authenticated TLS, a secured reverse proxy, or rosbridge authentication.
- Refuse plaintext remote connections by default. If plaintext is retained for local development, require an explicit flag such as
--allow-insecure-ws. - Restrict rosbridge at the network layer using host firewalls, VPNs, private interfaces, and allowlisted management hosts.
- Apply rosbridge or ROS-side authorization policies that allow only required topics and services instead of exposing the entire ROS graph.
- Separate read-only monitoring from state-changing operations and require explicit confirmation for movement, service calls, parameter changes, and actions.
- Document that rosbridge must not be exposed directly to untrusted networks and provide a secure deployment example.
- Add explicit support for