Bug: API endpoints ignore filter parameters instead of erroring when they are missing required filter predicates

[Reelix]

Description:

When making a GET request to the /api/v2/file-upload API endpoint, the id parameter does not correctly filter by the id of the job.

Are you intending to fix this bug?

No (Not at this time - Potentially later if unresolved for an extended period)

Component Affected:

• API

Steps to Reproduce:

1. Browse to /ui/administration/file-ingest and upload multiple files
2. Make an authorised GET request to the /api/v2/file-upload API endpoint and notice multiple items as data entries.
3. Attempt to filter by a specific id as per the GET /api/v2/file-upload documentation, eg /api/v2/file-upload?id=7

Expected Behavior:

The query returns containing only the data item where the id field matches the id filter.

Actual Behavior:

All items are returned.

Screenshot

Environment Information:

BloodHound: v7.3.1

Collector: NetExec 1.4.0

OS: Linux Mint 22.1

Go (if API related): Unknown (Running specterops/bloodhound:latest Docker image)

Database (if persistence related): As above

Docker (if using Docker): Docker Desktop 4.41.2 (191736)

Contributor Checklist:

• [ X ] I have searched the issue tracker to ensure this bug hasn't been reported before or is not already being addressed.
• [ X ] I have provided clear steps to reproduce the issue.
• [ X ] I have included relevant environment information details.
• [ X ] I have attached necessary supporting documents.
• [ X ] I have checked that any JSON files I am attempting to upload to BloodHound are valid.

[StephenHinck]

Hey @Reelix - I got further clarification from our team internally, and will update your report to match. The issue here is that your API call is missing a filter predicate that is necessary for the filter to apply. Your call should be /api/v2/file-upload?id=eq:7 (reference: https://bloodhound.specterops.io/reference/collection-uploads/list-file-upload-jobs#parameter-id).

Unfortunately, adding error handling support to this is a decently-sized work item. We will tackle it (and make sure that, when we implement v3 it's baked in from the start), but for now, please make sure you're adding predicates when called out in the API docs!

[Reelix]

Hi @StephenHinck - Thanks for the update!

In this case, the call was generated by the API itself by filling in the "id" value declared as an integer.

Whilst I understand that id=eq:7 is the solution, this seems to be an issue with how the API UI generates the associated requests. As such, this issue is less about the error handling itself (Which would indeed be a large undertaking!), and more about the generation from the API itself (eq:7 is not commonly an accepted integer value)

Attempting to use eq:7 in the id field in the UI throws an error that eq:7 is not an integer.

It would seem that either this value needs to be altered to a string (With an added description to give an example, although that may complicate things), or the generation itself needs to include the eq: section in the request (I am unsure if this is possible.)

[StephenHinck]

Hey @Reelix , you're correct - unfortunately Swagger doesn't handle the predicates well. We also want to replace that view altogether for similar reasons. We've got more coming and will keep you posted!