dangernoodle-io / breadboard / 30707415682

97%

push

github

fix: gate bb_ws_server WS handshake and frame delivery on provisioning state (#1182)

bb_ws_server registers its own httpd_uri_t directly via
httpd_register_uri_handler, bypassing bb_http.c's three existing
bb_http_prov_gate_check() insertion points entirely -- a WS endpoint
registered through this primitive was reachable, handshake and all
subsequent frames, by an unauthenticated SoftAP client regardless of
provisioning state (B1-1348). No in-tree component ships a WS endpoint
today, so nothing shipped is currently exposed, but there was no
lint/fence/test to catch a future consumer falling into the hole.

Two insertion points, not one:

- ws_pre_handshake_gate_cb, wired via httpd_uri_t.ws_pre_handshake_cb,
  runs before ESP-IDF ever sends the WS handshake response (confirmed
  against the vendored ESP-IDF 5.5.4 httpd_uri() source) -- a denied
  handshake never upgrades the connection at all. It also sends an
  explicit httpd_resp_send_err(req, HTTPD_404_NOT_FOUND, NULL) before
  returning ESP_FAIL: verified against httpd_txrx.c that httpd_resp_send
  has no dependency on WS handshake state (the request is still an
  ordinary, not-yet-upgraded HTTP request at this point), so a plain
  HTTP response is exactly as valid here as from any other handler. NULL
  usr_msg makes it byte-identical to what a genuinely-unregistered WS
  path gets from httpd_uri()'s own uri==NULL branch (also NULL usr_msg,
  via httpd_req_handle_err's no-custom-handler default) -- without this,
  a bare rejected handshake (zero bytes, socket just closes) was
  trivially distinguishable on the wire from that genuine miss, letting
  an unauthenticated SoftAP client fingerprint that a WS endpoint exists
  at a path without completing a handshake.
- ws_shim_handler re-checks the gate on every subsequent call (the
  handshake-completion call AND every real data frame after it), because
  a WS session is long-lived: it can complete its handshake while
  provisioning is inactive, then h... (continued)

8105 of 8678 branches covered (93.4%)

Branch coverage included in aggregate %.

11 of 11 new or added lines in 1 file covered. (100.0%)

13751 of 13906 relevant lines covered (98.89%)

2580.02 hits per line