AuthV2: Successful import but 403

DefectDojo / django-DefectDojo

DevSecOps, ASPM, Vulnerability Management. All on one platform.

https://defectdojo.com

BSD 3-Clause "New" or "Revised" License

3.62k stars 1.52k forks source link

AuthV2: Successful import but 403 #4347

Closed kiblik closed 3 years ago

kiblik commented 3 years ago

Bug description

Scan_User has permission only to import test results. Even process is successful, DD returns HTTP 403. It is a bit confusing.

Steps to reproduce

Log in as Scan_User
Go to https://xxx/engagement/xx/import_scan_results
Upload a valid scan

Deployment method (select with an X)

[x] Kubernetes
[x] Docker
[ ] setup.bash / legacy-setup.bash

Environment information

DD_FEATURE_AUTHORIZATION_V2=True
DefectDojo Commit Message: [2021-04-23 12:37:15 +0200] 952ebd0c: Bump easymde from 2.14.0 to 2.15.0 in /components (#4343) [ (HEAD, upstream/dev)]

Screenshots

valentijnscholten commented 3 years ago

What is the url you're seeing this? I think after the import the user is redirect to the view test page of the test that was just imported.

kiblik commented 3 years ago

http://localhost:8080/test/2 I know that showing 403 for Test makes sense but it is still confusing

valentijnscholten commented 3 years ago

Yes. I think the scan user was more designed for the API, but even there it needs some more permissions.

StefanFl commented 3 years ago

The scan_user role was actually designed for the API only. Using it in the UI seems to be an edge case for me, because you can't navigate to the Import page, you have to know the URL.

It is not easy to design the role for a scan_user. I personally have a script that gets the names for product, engagement and test. If it can't find the objects, it creates them and then does a reimport. Needs a lot of permission, the the user must be Maintainer.

StefanFl commented 3 years ago

Maybe it makes sense to give the scan_user role the permission to view the product and all objects underneath it (engagement, test, ...). Then the user can navigate to the product, import a scan result and view the result. But can't add or change anything manually.

kiblik commented 3 years ago

If Scan_User was designed to interact only from API, standard access can be totally denied.

StefanFl commented 3 years ago

Would it be clearer to change the name of the role to API_SCAN_USER?

kiblik commented 3 years ago

API_IMPORTER? "to import" is the only task for this user

pisces-period commented 3 years ago

Maybe it makes sense to give the scan_user role the permission to view the product and all objects underneath it (engagement, test, ...). Then the user can navigate to the product, import a scan result and view the result. But can't add or change anything manually.

A little bit late I suppose, but IMHO this is the better approach. It doesn't make much sense to create a role that is capable of interacting with the tool so much so as to update resources and not be able to see what it just did (?).

API_IMPORTER suggests that you can do imports via API - but it still sounds vague, as one might think that you can bulk import users, products, engagements etc via the API, which doesn't seem to be the case.

valentijnscholten commented 3 years ago

renamed role in 1.15.0