fix(notifications): scope rules to owner_id to prevent cross-tenant exfiltration (fixes #2064) - #2067
Conversation
…ross-tenant data exfiltration The process_finding_notifications function queried ALL active notification rules across ALL tenants without an owner_id filter. This allowed any authenticated user to passively receive all other users' scan findings by creating a notification rule pointing to their webhook. Now the notification rules query filters by the finding's owner_id, ensuring only rules belonging to the same tenant are evaluated. Fixes utksh1#2064
utksh1
left a comment
There was a problem hiding this comment.
The owner-scoped query is the right fix, but this critical boundary needs regression coverage. Please add tests showing a finding only triggers its own owner’s active rules and never delivers to another owner’s rule, then rerun checks.
utksh1
left a comment
There was a problem hiding this comment.
The query scoping is the right fix, but this security boundary needs direct regression coverage. Please add tests with two owners/rules proving a finding triggers only its owner rule and cannot deliver to another owner webhook, then rerun checks.
…rule isolation Add tests proving a finding only triggers notification rules belonging to its own owner and never delivers to another owner's webhook/rule. Also adds a test verifying inactive rules are not triggered.
…ient The app_client fixture overrides require_api_key to always succeed, causing test_unauthenticated_request_rejected and test_wrong_api_key_rejected to return 200 instead of 401. Added no_auth_app_client fixture that uses real auth for these tests.
|
@utksh1 fixed |
…tification-exfiltration
21bbd10 to
44bbc77
Compare
|
@utksh1 All admin review comments have been addressed and the branch is rebased onto the latest main (including the undici override fix), so all required checks are green and the PR is mergeable. Requesting re-review. Summary of changes in this PR:
|
Summary
Fixes a high-severity cross-tenant notification data exfiltration vulnerability where
process_finding_notificationsqueried ALL active notification rules without anowner_idfilter.Problem
The
process_finding_notificationsfunction innotification_service.pyfetched all active notification rules across all tenants, causing every finding to trigger delivery to every rule owner's webhook endpoint. This allowed any authenticated user to passively exfiltrate other users' complete scan results by creating a notification rule with a low severity threshold.Fix
owner_idfilter to the notification rules query inprocess_finding_notificationsImpact
Testing
Fixes #2064