Bug: attributes/restSearch silently ignoring RPZ-specific options

[JoePJisc]

Actual behavior

Since upgrading to v2.4.178 (we did jump a few versions with this upgrade):

url=https://misp.[removed]/attributes/restSearch
apikey=[removed]

curl -H "Content-Type: application/json" -H "Authorization: ${apikey}" --request POST -d '{"returnFormat": "rpz", "policy": "PASSTHRU", "attribute_timestamp": "100d", "tags": ["example:tag","example:tag2"]}' ${url}

Returns an RPZ zone with the default policy set in RPZ.policy (in our case Local-Data) and not the overwritten PASSTHRU making what should be a monitor zone a blocking zone. In trying to diagnose this issue, we found that setting policy to invalid-value and even renaming policy to invalid-policy return the same results too with nothing written to any logs that I can find about invalid arguments being discarded.

Expected behavior

If an API call (to any endpoint) has any invalid keys or values I'd expect a 400 Bad Request status code to be returned with a JSON object explaining the error, details of the invalid options should also be written to error.log or similar.

If a 200 response and / or content are returned then the requester (user or system) will assume all of the provided arguments were understood and applied.

Steps to reproduce

Make a POST request to attributes/restSearch for returnFormat rpz and attempt to override the default RPZ settings such as policy.
Make a POST request to attributes/restSearch and pass non-existent keys.
Make a POST request to attributes/restSearch and pass invalid values for existing keys.

Check the returned content and logs

Version

2.4.178

Operating System

RedHat

Operating System version

7

PHP version

7.4

Browser

No response

Browser version

No response

Relevant log output

None written other than web server access logs - part of the issue

Extra attachments

As a workaround for the specific issue we faced, we have found that POSTing the same request to attributes/rpz/download/ without the returnFormat option does produce a valid PASSTHRU zone as expected, though we are concerned the old endpoint we were targeting, which has worked for several years, suddenly failed with a routine update without any error being reported or logged.

Code of Conduct

• I agree to follow this project's Code of Conduct