Validate consistency between ID-based and name-based identifiers in import/reimport

[Jino-T]

• Add validation in the import and reimport permission checks to ensure that when both ID-based
  identifiers (e.g. test, engagement) and name-based identifiers (e.g. product_name, engagement_name) are
  provided, they refer to the same objects
• Add defense-in-depth checks in AutoCreateContextManager to reject conflicting resolution paths at the
  target lookup layer
• Add tests covering the new validation behavior

[mtesauro]

Approved

[dryrunsecurity]

This pull request introduces validation checks that compare user-supplied identifiers (e.g., test/engagement/product IDs or names) against resolved database objects before authorization checks, which can leak information via distinct ValidationError responses and enable enumeration of valid resource IDs and relationships (engagement→product) even to unauthorized users. The behavior reveals object existence and associations by returning 400 errors for mismatches instead of 403 permission errors, posing a low-severity information disclosure risk.

Resource Enumeration via Validation Error in dojo/api_v2/permissions.py (drs_eaf4608f)

Vulnerability

Resource Enumeration via Validation Error

Description

The code introduces explicit validation checks that compare user-provided identifiers (e.g., product/engagement names or IDs) against resolved database objects before performing an authorization check (user_has_permission). By submitting various combinations of identifiers (both valid and invalid/mismatched), an unauthorized user can receive distinct ValidationError messages or observe different response behaviors based on whether the resolved test object exists and its relationships to the provided parameters. This allows for the systematic enumeration of valid test IDs, their associated engagements, and parent products, as well as the inference of their specific names via error messages.

django-DefectDojo/dojo/api_v2/permissions.py

Lines 792 to 794 in 70c2c19

	if (engagement := converted_dict.get("engagement")) and test.engagement_id != engagement.id:
	msg = "The provided identifiers are inconsistent — the test does not belong to the specified engagement."
	raise ValidationError(msg)

Resource Enumeration via Validation Error in dojo/api_v2/permissions.py (drs_86777e02)

Vulnerability

Resource Enumeration via Validation Error

Description

The validation check happens after the objects (engagement and product) have already been fetched from the database, likely using system-level privileges or public read access. By comparing whether an engagement belongs to a product and raising a ValidationError (400 Bad Request) when they do not match, the application reveals whether a specific engagement belongs to a specific product. This is distinguishable from a PermissionDenied (403 Forbidden) error, which would be returned if the user lacks access to the object. An attacker can use this difference to enumerate existing relationships between resources even if they lack direct read access to those resources.

django-DefectDojo/dojo/api_v2/permissions.py

Lines 477 to 479 in 70c2c19

	if (product := converted_dict.get("product")) and engagement.product_id != product.id:
	msg = "The provided identifiers are inconsistent — the engagement does not belong to the specified product."
	raise ValidationError(msg)

---

Comment to provide feedback on these findings.

Report false positive: @dryrunsecurity fp [FINDING ID] [FEEDBACK]
Report low-impact: @dryrunsecurity nit [FINDING ID] [FEEDBACK]

Example: @dryrunsecurity fp drs_90eda195 This code is not user-facing

All finding details can be found in the DryRun Security Dashboard.