62 lines
4.2 KiB
Markdown
62 lines
4.2 KiB
Markdown
# Server-Side Password Authentication Flow Assessment (Batch 3)
|
||
|
||
**File inspected:** `crates/cgcx-server/src/main.rs`
|
||
|
||
## Flow Verification
|
||
|
||
### 1. `get_metadata` handler (`/api/content/:cxid`)
|
||
- **Lines ~496–568**
|
||
- Sequence:
|
||
1. Content status check (Deleted/Blacklisted) → **404 NotFound**
|
||
2. Max-views check (`content.view_count >= max`) → **410 Gone**
|
||
3. Password validation via `password_from_request(&headers, query.sc.as_deref(), ...)` → **401 Unauthorized** if invalid
|
||
4. Returns metadata JSON if all checks pass
|
||
- **View increment:** None. Metadata requests do not consume auto-destroy views.
|
||
- **Conclusion:** Password check is enforced and returns 401 on failure. ✅
|
||
|
||
### 2. `serve_file` handler (`/api/content/:cxid/file/:file_idx`)
|
||
- **Lines ~700–890**
|
||
- Sequence:
|
||
1. Content status check → **404**
|
||
2. Max-views check → **410**
|
||
3. Password validation via `password_from_request` → **401** if invalid
|
||
4. Download permission check → **403 Forbidden** if `?download=true` but not allowed
|
||
5. File lookup, path-traversal validation, ETag conditional check (304)
|
||
6. Range header parsing
|
||
7. **View increment at line ~825:** `repo.increment_views(&content_id).await?`
|
||
8. If `new_views >= max`, spawns background auto-delete task after 30s
|
||
9. Streams decrypted file body
|
||
- **Conclusion:** View increment happens **after** password validation and all other guards. Unauthorized requests cannot consume views. ✅
|
||
|
||
### 3. `password_from_request` helper
|
||
- **Lines ~436–475**
|
||
- Validates `sc` query parameter using Argon2 (`PasswordHash::new` + `Argon2::default().verify_password`).
|
||
- Falls back to `cgcx_pw` cookie verified with HMAC-SHA256 and `subtle::ConstantTimeEq`.
|
||
- Returns `None` on any mismatch, causing the caller to return 401.
|
||
- **Conclusion:** Argon2 verification is present and constant-time. ✅
|
||
|
||
### 4. `serve_raw_file` handler (`/api/content/:cxid/file/:file_idx/raw`)
|
||
- **Lines ~920–1020**
|
||
- Sequence mirrors `serve_file` for status, max-views, and password checks.
|
||
- **View increment:** None. This endpoint never increments `view_count`.
|
||
|
||
---
|
||
|
||
## Edge Cases & Concerns
|
||
|
||
| # | Edge Case | Impact | Risk |
|
||
|---|-----------|--------|------|
|
||
| 1 | **`serve_raw_file` skips view increment** | Requests to the `/raw` endpoint do not consume auto-destroy views. A user could repeatedly preview raw text without triggering deletion. | Medium — bypasses view-count enforcement for text content previews. |
|
||
| 2 | **Zero-size files in `serve_file` return early** | The zero-size branch (line ~751) returns a response **before** the increment block, so zero-byte files never consume a view. | Low — niche, but technically bypasses max-views for empty files. |
|
||
| 3 | **Range/conditional/HEAD requests skip increment** | `serve_file` only increments when `!is_range && !is_conditional && !is_head`. Video/audio seeking (range requests), cache revalidation (If-None-Match), and HEAD probes do not count as views. | Low — intentional for UX, but means views are under-counted. |
|
||
| 4 | **Max-views checked before password validation** | In all three handlers, if `view_count >= max`, a request with a wrong password receives **410 Gone** instead of **401 Unauthorized**. This leaks that the content existed and exhausted its views without requiring the password. | Low — information disclosure about content lifecycle. |
|
||
| 5 | **TOCTOU race on view increment** | `content.view_count` is read in `repo.get()` and incremented later in a separate statement. Under concurrent requests, two clients could both pass the initial `view_count < max` check and both increment, causing `view_count` to exceed `max`. Both requests are still served. | Low — SQLite serializes writes via `conn.lock()`, but the read-write gap still allows one extra view. |
|
||
|
||
---
|
||
|
||
## Conclusion
|
||
|
||
- **Password authentication flow is correct.** Wrong passwords receive 401 and do **not** increment view counts.
|
||
- **No server changes are required for Batch 3.** The frontend password fix (if any) is independent of server behavior.
|
||
- The identified edge cases are pre-existing behaviors. None are blockers for Batch 3, but items 1 (`serve_raw_file` bypass) and 5 (TOCTOU race) may be worth addressing in a future hardening pass if auto-destroy accuracy is critical.
|