Pentest fixes and hardening#321
Conversation
Adds nav-bar chip that polls /admin/api/updates/available every 6h and shows a confirm dialog to trigger an update. Adds polling progress dialog that opens on update-started event and tracks /admin/api/updates/status at 2s intervals until the run completes.
…through serialize/validation
…cal/bin, exempt /health from setup redirect
…host+no-password (matches backup_utils.py)
|
BAY-01-015 looks fixed. I tested by changing the export ID in the URL/API to another user’s export. The server returned 403 Forbidden, so the export metadata is no longer exposed. Minor note: 403 vs 404 can still hint that an export ID exists, but that is low impact and not the main issue. Unrelated UX issues noticed while testing:
|
Bulletin/Actor to_dict() embedded full media metadata (filename, etag, title, OCR extraction text) in the medias array for any user who could read the parent, even those blocked from the media endpoints by _require_media_access. A non-Admin without can_access_media therefore still received the data the direct endpoints deny them. Gate the medias loop on a shared can_view_media() helper that mirrors the _require_media_access policy (Admin or can_access_media) and trusts CLI/Celery via has_request_context, matching check_history_access.
The single-OCR endpoint requires can_edit (assignment boundary) since OCR writes an extraction, but /api/ocr/bulk scoped items only by can_access (visibility), letting a non-Admin with can_access_media OCR-mutate media they can read but are not assigned to edit. Post-filter the resolved media ids by can_edit for non-Admins. The query-level access filter can't express can_edit (needs the parent's assignment + status), so it is done in Python; Admins skip the filter.
|
BAY-01-018 looks fixed for the main reported issue. I tested a bulk Bulletin update as a Mod with:
Only Bulletin 12 was updated. Activity Monitor only showed Bulletin 12, and only Bulletin 12 got a new revision history entry. Separate issue found while testing Incident bulk updates: Test:
Result: So the original restricted-ID logging issue seems fixed, but assignRelated can still create duplicate history entries for related Bulletins. |
|
BAY-01-022 looks fixed for the normal Bulletin update API, but I found a remaining bulk-update edge case. Test:
So the normal edit path is protected, but bulk update can still mutate peer-review-locked Bulletins. |
# Conflicts: # enferno/commands.py # enferno/settings.py # uv.lock
…I, export all media with access filter, actor name fallback)
…s under hardened DB role
… bootstrap, and health/update endpoints
…ap on low-memory boxes
…e redis decode and CSV access checks
Fixes for the 7ASec BAY-01 engagement, on top of baseline
8615ff11b. One commit per finding, taggedfix(BAY-01-NNN):so the retest maps fixes bygit log --grep BAY-01 pentest-fixes.42 of 43 fixed. Open:
BAY-01-017(release signing), a product decision, not a code gap.Finding to commit
017 is unaddressed pending the signing decision. minisign keypair exists, public key pinned; manual
sudo bayanat updatestays as the fallback.Partials worth flagging
020: filename enumeration closed (opaque names). Per-item auth on/api/serve/inline/<filename>is a separate parent-binding change, deferred.028issue 6: passwords are out of argv (in-container config file +REDISCLI_AUTH). Delivery stays via env vars because Compose can't mount env-sourced secrets intoread_onlycontainers.031: app DB role stripped of superuser/createdb/createrole/replication and CONNECT revoked from PUBLIC, but keeps table ownership because dynamic-fields runsALTER TABLEat runtime.Retest
Backend regression tests:
uv run pytest tests/test_pentest_fixes.py. No frontend harness in this repo; 034 verified by review. Each commit message has root cause and where to verify. Fresh install recommended (005 changed the install flow: the installer now generates and prints the admin password once).