refactor dojo async task base task

[valentijnscholten]

The custom decorators that we have on Celery tasks interfere with some (advanced) celery functionality like signatures. This PR refactors this to have a clean base task that passes on context, but does not interfere with celery mechanisms.

The logic to decide whether or not the task is to be called asyncrhonously is now in a dispatch method.

Pro needs similar changes via https://github.com/DefectDojo-Inc/dojo-pro/pull/973, these must be merged "at the same time".

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[valentijnscholten]

I have had to include the commits from #14090 in this PR to make sure the downstream Pro codebase still works.

[valentijnscholten]

i've also had to include the commits from #14109 to make the downstream Pro codebase work.

[valentijnscholten]

And then I had to include the commits from #14080 to fix other errors in Pro.

[dryrunsecurity]

🟡 Please give this pull request extra attention during review.

This pull request introduces a risky SSRF vulnerability: the update_jira_epic view forwards user-controlled request.data directly into dojo_dispatch_task (which calls jira_helper functions that make HTTP requests to JIRA) without validating or allowlisting URL/host values, allowing an attacker to cause the server to make requests to arbitrary or internal hosts.

🟡 Potential Server-Side Request Forgery (SSRF) in dojo/api_v2/views.py

Vulnerability

Potential Server-Side Request Forgery (SSRF)

Description

The view update_jira_epic dispatches jira_helper.update_epic / add_epic with **request.data passed directly into dojo_dispatch_task. The dispatch implementation (in the provided patch) injects user context and either executes the Celery signature async or runs it synchronously, but it does not validate or allowlist any URL/hostname values that may be inside request.data. The jira helper functions ultimately perform HTTP requests to JIRA (push/update/add epics). Since request.data is user-controlled and forwarded into the task kwargs without sanitization, an attacker could include malicious URL/host fields (or other parameters used by the Jira helper) that cause the server to make requests to arbitrary/internal hosts, meeting SSRF criteria.

django-DefectDojo/dojo/api_v2/views.py

Lines 679 to 691 in e4da98a

	try:
	if engagement.has_jira_issue:
	dojo_dispatch_task(jira_helper.update_epic, engagement.id, **request.data)
	response = Response(
	{"info": "Jira Epic update query sent"},
	status=status.HTTP_200_OK,
	)
	else:
	dojo_dispatch_task(jira_helper.add_epic, engagement.id, **request.data)
	response = Response(
	{"info": "Jira Epic create query sent"},
	status=status.HTTP_200_OK,

---

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