Skip to content

Scope Tool Product Settings tool selection to authorized tool configurations - #4

Open
svader0 wants to merge 1 commit into
bugfixfrom
claude/reverent-neumann-ce0eaf
Open

Scope Tool Product Settings tool selection to authorized tool configurations#4
svader0 wants to merge 1 commit into
bugfixfrom
claude/reverent-neumann-ce0eaf

Conversation

@svader0

@svader0 svader0 commented Jul 31, 2026

Copy link
Copy Markdown
Owner

Description

ToolProductSettingsForm declared tool_configuration = ModelChoiceField(queryset=Tool_Configuration.objects.all()), and ToolProductSettingsSerializer uses fields="__all__", so any user who could reach the Tool Product Settings form or REST endpoint could select or POST any Tool_Configuration — an admin-held third-party credential — regardless of whether they were authorized to view it.

Same unscoped-queryset authorization gap that DefectDojo/django-DefectDojo#15445 (H1 #3900540) fixed for Product_API_Scan_ConfigurationForm. Lower risk here because the tool_product view never runs test_product_connection (no immediate outbound credential replay), but it's the same gap and is closed for consistency.

Fix:

  • Scope the form field queryset in ToolProductSettingsForm.__init__(user=...) via get_authorized_tool_configurations(user) — gates both the rendered choices and the accepted POST value, so narrowing the <select> can't be bypassed by POSTing the id. request.user is passed from all tool_product views (new / edit / delete).
  • Validate the writable tool_configuration in ToolProductSettingsSerializer (PATCH-safe: no-op when the field is absent) so the REST endpoint is gated too.
  • Reuses the get_authorized_tool_configurations helper introduced in Scope API scan configuration tool selection to authorized tool configurations DefectDojo/django-DefectDojo#15445; dojo/tool_config/queries.py is included here identically so this branch is self-contained and merges cleanly with it.

Test results

Adds unittests/test_tool_product_settings_tool_authz.py, mirroring test_api_scan_configuration_tool_authz.py: an unprivileged user is offered no configurations, cannot submit a config id (form and REST both reject), and a privileged user still can. Not run locally (the running stack mounts a different checkout); executes in CI.

Documentation

None needed — internal authorization fix, no behavior change for authorized users.

Checklist

  • Submitted against the bugfix branch (bug fix).
  • Unit tests added.
  • No DB migration required (no model changes).

ToolProductSettingsForm offered every Tool_Configuration regardless of the
user's permissions, and ToolProductSettingsSerializer (fields="__all__")
accepted any tool_configuration id. Tool configurations hold shared
third-party credentials gated by view_tool_configuration, so a user who
cannot view them must not be able to select or submit one -- via the UI or
the REST API. Same authorization gap as the API scan configuration fix
(H1 #3900540), lower risk here since tool_product does not replay the
credential, but closed for consistency.

Scope the form field queryset via get_authorized_tool_configurations(user)
(passed from all tool_product views) and validate the same field in the
serializer. Reuses the helper added for #3900540. Adds a regression test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@svader0
svader0 force-pushed the claude/reverent-neumann-ce0eaf branch from 3dbffbb to 063f7a1 Compare July 31, 2026 17:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant