Closed JasonMortonNZ closed 1 year ago
This is another issue of "improper" handling of request parameters. In this case period
is provided as an array, which we expect to be a string.
Personally I would not suggest to fix all such incorrect handling were they occur, as it consumes a lot of time and actually doesn't improve much. The result for the customer will only change from a php error to an unsupported param
exception.
We should maybe consider for Matomo 5, to introduce a proper request param handling for API methods.
Each api method could define the types of the method parameters using type hints (or maybe doc comments where multiple types are allowed 🤔). Our API request processor could then check if the provided values can be converted/mapped to the defined types. If that isn't the case a general exception like Parameter X expects type Y, but Z provided.
could be thrown.
Maybe we should create a global issue for that. (ping @justinvelluppillai)
I think a global issue could be good for this. I might be completely out of context here but ideally it would return a 422 code because it is a user correctable error and avoid any exceptions. Would likely need light validations for such a implementation though. I think stopping such invalid input earlier might help with security too. Being able to hit methods such as preg_match etc can provide a vuln sometimes.
The following error has been popping up recently:
Steps to Reproduce (for Bugs)
URL: https://matomo.test/index.php?date=yesterday&format=JSON&idSite=1&idSites=1,2&method=API.getReportMetadata&module=API&period[$acunetix]=1&token_auth=XYZANONYMIZED
Referrer:
GET: {"date":"yesterday","format":"JSON","idSite":"1","idSites":"1,2","method":"API.getReportMetadata","module":"API","period":{"$acunetix":"1"},"token_auth":"XYZANONYMIZED","filter_limit":100}
Your Environment