SEC-NB-001 — Verify identity and kernel ownership on WebSocket upgrade
| Field | Value |
|---|---|
| Status | Open; source-verified, security validation pending |
| Architecture state | Source-backed trust boundary |
| Severity | Critical |
| Affected surface | Notebook kernel-channel WebSocket upgrade |
| Components | sparqd/bff-api; JupyterHub and Jupyter Server are upstream dependencies |
| Associated issue | bff-api #229 |
Where the problem appears
The BFF upgrades the browser connection for a caller-supplied kernel channel and opens the upstream user-server connection with a privileged Hub credential.
Concrete observed case
Reviewed bridge source decodes the browser token to obtain a username but does not visibly verify its signature, issuer, audience, expiry, workspace, or ownership of the requested kernel in the upgrade handler.
Expected condition
Every upgrade cryptographically authenticates the caller and authorizes the user, workspace, server, and kernel relationship before any privileged upstream connection is opened.
Cause and evidence
The custom upgrade path does not share a demonstrated equivalent of the normal HTTP authentication and resource-ownership boundary. It trusts decoded claims and a URL kernel identifier before using an administrative credential upstream.
Why it matters
If no earlier verified boundary supplies these checks, a forged or misplaced identity could access another kernel through a highly privileged proxy path.
Existing controls and workarounds
Network placement and the upstream Hub credential constrain reachability, but they do not prove caller identity or resource ownership. Do not attempt an exploit in the deployed workspace; use source tracing and approved security tests.
Alternatives considered
- Recommended: verify the token and authorize kernel ownership before upgrade, then use the narrowest upstream credential available.
- Depend on network access alone — rejected because it is not identity or resource authorization.
- Continue using decoded claims — rejected unless an earlier enforced upgrade boundary is demonstrated and covered by tests.
Component involvement
sparqd/bff-apiowns authentication, workspace binding, authorization, and upstream credential scope for the bridge.- JupyterHub/Jupyter Server provide the authoritative user-server and kernel relationship that must be checked.
Reproduction and verification
Use the approved authorization matrix in NB-S005. Do not retain tokens or probe another user's live kernel.
Resolution conditions
Close after security review demonstrates cryptographic verification, audience and workspace binding, kernel ownership enforcement, denial tests, and safe audit records on the actual upgrade path.
Validation and blockers
The source concern is confirmed. Security review must determine whether an earlier infrastructure layer already performs equivalent enforcement.