T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- src/web/server.js:19
- Finding
- Unauthenticated WebSocket API Exposes Messaging Data and Privileged Operations<![CDATA[ ## Vulnerability Details **File Location**: `src/web/server.js:19-23`; `src/web/api.js:55-72` **Vulnerability Type**: Missing authentication and WebSocket Origin validation **Risk Level**: High ### Vulnerable Code `src/web/server.js:19-23`: ```js // WebSocket: デフォルトはローカルホストのみ、--lan で LAN 公開 const wss = new WebSocketServer({ server, maxPayload: 1024 * 1024 }) wss.on('connection', (ws) => { createApiHandler(ws) }) ``` `src/web/api.js:55-72`: ```js // 接続確立時に初期データを送信 const identity = identityStore.load() if (identity) { sendEvent('init', { data: { number: identity.number, inbox: buildInbox(), contacts: buildContacts(), prefs: { theme: 'dark' } }}) } ws.on('message', async (raw) => { let msg try { msg = JSON.parse(raw.toString()) } catch { return } await dispatch(msg) }) ``` ### Technical Analysis The WebSocket server accepts every connection and immediately passes it to `createApiHandler` without authenticating the client, validating a session token, or checking the HTTP `Origin` header during the upgrade. Once connected, the API sends initialization data containing the local identity number, inbox, contacts, PIN records, message metadata, and latest messages. The same connection can submit commands handled by `dispatch`, including operations that: - List stored messages and contacts. - Send messages and files. - Create, rotate, or revoke PINs. - Add, modify, or remove contacts. - Renew the user's number. - Register notification tokens. Binding to `127.0.0.1` by default is not a sufficient authorization boundary. A malicious web page may attempt a cross-site WebSocket connection to a predictable local port. In addition, the documented `--lan` option binds the service to `0.0.0.0`, making the unauthenticated interface directly reachable by other devices on the same network. LAN traffic is also served over plaintext HTTP and WebSocket protocols. ### Attack Path 1. The victim starts the web interface using `c0x0 web`, ...[truncated 1656 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Generate a cryptographically random, high-entropy session token each time the web server starts. 2. Require the token during the WebSocket upgrade, preferably through an authorization mechanism that does not expose it to unrelated origins. 3. Validate the WebSocket `Origin` header against an explicit allowlist and reject missing or unexpected origins. 4. Validate the request host and upgrade path rather than accepting WebSockets on every route. 5. For LAN mode, require explicit authentication and display a clear warning that the interface exposes private conversations and account-management operations. 6. Use TLS (`HTTPS` and `WSS`) for all non-loopback access. 7. Consider separating read-only and state-changing operations and requiring reauthorization for destructive actions such as PIN revocation or number renewal. 8. Avoid returning raw PIN values and full message details in the initial event unless they are required by the active view. 9. Add connection rate limits, command-level authorization checks, and security tests covering hostile Origin headers and unauthenticated LAN clients. ]]>