Two request-security fixes found in a review of the plugin (the first on this repo).
SQL injection via the filter search (CA, proxy, credential pages)
servcheck_ca.php, servcheck_proxy.php, and servcheck_credential.php registered the filter request variable as FILTER_DEFAULT (no sanitization) and concatenated it raw into a LIKE clause, so a servcheck-realm user could inject SQL through the filter GET parameter (the CA query was also malformed). servcheck_test.php already does this correctly with sanitize_search_string; this aligns the other three and additionally builds the LIKE value with db_qstr, closing the injection regardless of the sanitizer, and fixing the broken CA search.
CSRF on the enable / disable / purge GET actions
servcheck_test.php ran enable, disable, and purge (which deletes a check's log history) from a plain GET with no CSRF check — a crafted link could disable monitoring or purge history when an authenticated admin loaded it. The action now validates csrf_guard()->validate() against the __csrf_magic token, which the action links carry via csrf_get_tokens() (Cacti's own CSRF API; csrf_check() only guards POST).
Both post-auth (servcheck admin realm). php -l and php-cs-fixer clean; no behaviour change for a normal search or a legitimately-clicked action.
Tracking issue for #90, which carries the fix.
Two request-security fixes found in a review of the plugin (the first on this repo).
SQL injection via the
filtersearch (CA, proxy, credential pages)servcheck_ca.php,servcheck_proxy.php, andservcheck_credential.phpregistered thefilterrequest variable asFILTER_DEFAULT(no sanitization) and concatenated it raw into aLIKEclause, so a servcheck-realm user could inject SQL through thefilterGET parameter (the CA query was also malformed).servcheck_test.phpalready does this correctly withsanitize_search_string; this aligns the other three and additionally builds theLIKEvalue withdb_qstr, closing the injection regardless of the sanitizer, and fixing the broken CA search.CSRF on the enable / disable / purge GET actions
servcheck_test.phpranenable,disable, andpurge(which deletes a check's log history) from a plain GET with no CSRF check — a crafted link could disable monitoring or purge history when an authenticated admin loaded it. The action now validatescsrf_guard()->validate()against the__csrf_magictoken, which the action links carry viacsrf_get_tokens()(Cacti's own CSRF API;csrf_check()only guards POST).Both post-auth (servcheck admin realm).
php -land php-cs-fixer clean; no behaviour change for a normal search or a legitimately-clicked action.Tracking issue for #90, which carries the fix.