- Issue created by @alexpott
This module does not treat user input as potentially incorrect or malicious which leads to a potential DDOS via filling up the cache via making requests with different parameters.
You can see this issue by:
jsonapi/menu_items/main?filter%5Bconditions%5D%5Bprovider%5D%5Bvalue%5D=jsonapi_menu_items_test&filter%5Bconditions%5D%5Bprovider%5D%5Boperator%5D=something%20it%20should%20not%20beI think a user could use this route to complete fill up the cache by passing different parameters to the filter as these are serialised and used as a cache key in \Drupal\Core\Menu\MenuTreeStorage::loadTreeData().
I think we need to adjust \Drupal\jsonapi_menu_items\Resource\MenuItemsResource::applyFiltersToParams() to become much stricter about what it accepts to reduce cache entries and prevent a user from being able to set the operator value to whatever they like. I believe the protection in \Drupal\Core\Database\Query\Condition::compile() prevents SQL injection so this is not a security issue. I've tried setting operator to an array and fortunately that triggers a 500.
Note: this issue was discussed in https://security.drupal.org/node/183477 and agreed that it can be public.
Here are the following things I think we should ensure:
I'm not sure how to deal with condition.field_name.value - i think given this ends up in the menu storage cache we maybe need a way to disable writing to cache for this JSON API menu storage load so that we just rely on response caching. We have a similar problem for parent and parents - I'm not sure how we can prevent a user from being able to fill up the menu storage cache by making a gazillion requests with different params.
Review the MR
None
None
Active
1.2
Code
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.