fix(security): path-traversal guard on 5 sensing-server endpoints (closes #615)

[ruvnet]

Closes #615 — credit @bannned-bit for the precise exploit catalogue and the fix template.

Five vulnerable endpoints, all patched

File	Endpoint	Param	What an attacker could do pre-fix
recording.rs	POST /api/v1/recording/start	session_name	Write JSONL to arbitrary location via ../../-prefixed name
recording.rs	GET /api/v1/recording/download/:id	id	Read any file the server process can access (../../.env, /etc/passwd)
recording.rs	DELETE /api/v1/recording/delete/:id	id	Delete arbitrary files (config, recordings)
model_manager.rs	POST /api/v1/models/load	model_id	Load attacker-controlled .rvf file from arbitrary path
training_api.rs	load_recording_frames (internal, exposed via /api/v1/train/start)	dataset_ids[]	Read arbitrary files as training input

All five built filesystem paths via format!("...{user_input}...") with no validation. The replace(' ', "_") in recording.rs only normalised whitespace — it did nothing against .., /, null bytes, etc.

Fix shape

New wifi_densepose_sensing_server::path_safety module exports:

pub fn safe_id(input: &str) -> Result<&str, PathSafetyError>

Rejection envelope:

• Allowed characters: [A-Za-z0-9._-]
• Reject leading . (rules out ., .., .env, hidden files)
• Reject empty strings
• Reject anything > 64 bytes (MAX_ID_LEN)
• Reject all whitespace, path separators (/, \), null bytes, non-ASCII (including the fullwidth slash U+FF0F which can normalise to / on some filesystems)

Applied at all 5 sites before any user input reaches a format!() that builds a path. Errors return 400 Bad Request (download) or status: "error" JSON (others) — not panics. Stay consistent with the existing error response shapes.

Test coverage

9 unit tests in path_safety::tests:

test path_safety::tests::accepts_simple_alphanumeric ... ok
test path_safety::tests::boundary_max_len ... ok
test path_safety::tests::rejects_parent_directory_traversal ... ok
test path_safety::tests::rejects_path_separators ... ok
test path_safety::tests::rejects_too_long ... ok
test path_safety::tests::rejects_whitespace_and_specials ... ok
test path_safety::tests::rejects_non_ascii ... ok
test path_safety::tests::rejects_null_byte ... ok
test path_safety::tests::rejects_empty ... ok
test result: ok. 9 passed; 0 failed

cargo build -p wifi-densepose-sensing-server --no-default-features — 33s, no errors (one pre-existing unused-import warning unchanged).

Regression guard

Fix-marker RuView#615 in scripts/fix-markers.json requires both path_safety::safe_id (called sites) and pub fn safe_id (the helper itself). Removing the guard at any of the 5 call sites or deleting the module would fail CI.

$ python scripts/check_fix_markers.py
…
[PASS] RuView#615   path_safety::safe_id gates user-controlled IDs at filesystem boundaries
…
All 19 fix markers present.

Why this is severity-critical

All 5 endpoints are unauthenticated when RUVIEW_API_TOKEN is unset (the LAN-mode default from #443). Combined with the recent #580 (host-header allowlist for DNS rebinding) — both classes of attack land same-origin from any page the user visits during a sensing session. This PR closes the filesystem-side hole; #580 already closed the cross-origin reach.

Audit completeness

grep -rn 'format!("[^"]*\\{[^}]*_id[^}]*\\}' v2/crates/wifi-densepose-sensing-server/src/ — the 5 sites in the PR are the only matches that touch user-controlled identifiers AND build a filesystem path. Other format! calls in that crate either build URLs (host_validation), log messages, or use server-internal identifiers.

🤖 Generated with claude-flow