You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The search field that's present on most of the listing pages in the admin screens (for example, API Backends, API Users, etc) could fail to return results as expected if you searched for special characters. For example, if you searched for (foo, you'd get alert errors. Searching for other special characters may have resulted in no search results at all.
The reason for the issues was that we were treating these searches as regular expressions, rather than a simple "contains" type of search. This regex handling wasn't intended and caused for this type of unintuitive behavior when your searches happened to contain any regex special characters.
The other issue with the regex handling was that the regexes could potentially be abused by a nefarious admin to eat CPU cycles on our servers (see regular expression denial of service). This was limited to admins, since they were the only ones that could hit these endpoints, and we never saw any activity like this, but regardless, it's good to mitigate this type of issue.
The text was updated successfully, but these errors were encountered:
We now escape regex characters for all searches to mitigate this: NREL/api-umbrella@a528416 We're also now running brakeman as part of our normal test suite, which helps identify security issues like this.
The search field that's present on most of the listing pages in the admin screens (for example, API Backends, API Users, etc) could fail to return results as expected if you searched for special characters. For example, if you searched for
(foo
, you'd get alert errors. Searching for other special characters may have resulted in no search results at all.The reason for the issues was that we were treating these searches as regular expressions, rather than a simple "contains" type of search. This regex handling wasn't intended and caused for this type of unintuitive behavior when your searches happened to contain any regex special characters.
The other issue with the regex handling was that the regexes could potentially be abused by a nefarious admin to eat CPU cycles on our servers (see regular expression denial of service). This was limited to admins, since they were the only ones that could hit these endpoints, and we never saw any activity like this, but regardless, it's good to mitigate this type of issue.
The text was updated successfully, but these errors were encountered: