dangernoodle-io / breadboard / 30599228805

97%

push

github

fix: mask secrets before logging, never print SoftAP/WiFi passwords in plaintext (#1158)

Audit found ONE plaintext-secret leak site: platform/espidf/bb_wifi_ap/
bb_wifi_ap.c's AP-started log line printed the provisioning SoftAP password
verbatim ("SSID=..., password=..."). Every other candidate path was already
clean:
- user WiFi creds (bb_wifi_prov/bb_wifi/bb_wifi_http/bb_settings): password
  is read via bb_settings_wifi_pass_get() and friends and passed straight
  into esp_wifi's wifi_config_t -- every read site already carries a
  "never log the password value" comment, and none do.
- GET /api/wifi and /api/diag/wifi never include a password field in their
  wire descriptors (only the PATCH request body accepts one, write-only).
- /api/diag/storage/nvs (the NVS dump) exposes ns/key/type/label/len/flags
  (including a `secret` boolean) but never the stored value.
- validation/error paths (bb_wifi_prov_parse_body, PATCH /api/wifi apply)
  return enum result codes, never echo the offending value.
- MQTT client logs uri/tls only (never username/password); TLS client
  cert/key material is never passed through a log call anywhere.
- no OTA token/API-key/bearer-auth concept exists in this repo.

Fix: bb_log_secret(level, tag, label, secret) in bb_log (components/bb_log/
src/bb_log_secret.c) is now the only sanctioned way to put a secret-derived
value into a log line. It reads the secret's bytes exactly once (to
classify unset vs set) and never passes them through a printf-style format
-- there's no call shape that leaks the raw value through this function.
The vulnerable bb_wifi_ap.c call site now routes through it instead of
hand-interpolating the password into a %s. tag/label are normalized to "?"
when NULL before they hit the internal "%s" format (only `secret` had
documented NULL-safety before; a NULL tag/label was UB per the C standard).

Masking rule: full, fixed-width redaction ("***"), not partial/
length-preserving -- a length-preserving mask ... (continued)

8074 of 8650 branches covered (93.34%)

Branch coverage included in aggregate %.

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

13657 of 13812 relevant lines covered (98.88%)

2597.78 hits per line