hardening: enforce POST+CSRF for purge syslog devices utility

[somethingwithproof]

Summary

• require POST before executing the purge_syslog_hosts utility action
• explicitly validate CSRF tokens using csrf_check(false) (with __csrf_magic fallback if csrf helper is unavailable)
• replace the GET action link in utilities UI with a JS POST flow that includes __csrf_magic
• add regression coverage for purge CSRF hardening
• run regression scripts from CI when tests/regression/*.php exist
• add changelog entry for issue hardening: require POST + CSRF token for purge_syslog_hosts utility action #259

Validation

• php -l setup.php
• php -l tests/regression/issue259_csrf_purge_test.php
• php tests/regression/issue259_csrf_purge_test.php

Fixes #259

[Copilot]

Pull request overview

Hardens the Syslog plugin’s “Purge Syslog Devices” utility by requiring the action to be executed via a POST flow intended to include CSRF protection, rather than a direct GET link, preserving the existing redirect/message behavior after execution.

Changes:

• Added a server-side POST + __csrf_magic presence check before running purge_syslog_hosts.
• Replaced the utilities UI GET link with a button-driven JS POST flow that submits action=purge_syslog_hosts plus CSRF token data.
• Kept the post-action redirect back to utilities.php with UI messaging.

[Copilot]

PR metadata says this change “Fixes #255”, but issue #255 is about SQL concatenation in the legacy syslog_manage_items() batch path (e.g., message LIKE '%...%' / type='sql' clauses in functions.php). This PR only hardens the utilities purge action flow, so it doesn’t appear to address the referenced issue as described. Either update the PR description/linked issue, or include the SQL hardening changes for #255 in this PR.

[somethingwithproof]

PR references #259 (CSRF purge), not #255. The issue number in the description is correct.

[Copilot]

The current CSRF gate only checks for the presence of __csrf_magic and does not validate the token value. If CSRF-magic isn’t already enforcing server-side validation for this endpoint, an attacker could supply an arbitrary __csrf_magic value and still pass this check. Prefer invoking the standard Cacti CSRF validation mechanism for POST actions (or otherwise explicitly validate the token), while keeping the POST-only requirement.

[somethingwithproof]

Primary validation uses csrf_check(false) when available; the __csrf_magic presence check is the fallback for environments without the csrf helper.

[somethingwithproof]

Addressed review feedback in the latest commit set:

• corrected issue linkage to Fixes #259
• enforced POST-only request handling for purge action
• added explicit CSRF token validation via csrf_check(false)
• added regression coverage (tests/regression/issue259_csrf_purge_test.php) and CI regression execution

[TheWitness]

We don't use confirm in Cacti. We should likely have a confirm plugin like with Bootstrap that generates a jQuery Dialog though. If you can make that happen, then this can be merged.

I'm wondering though, if the purge button can simply have it's action switched to loadPageUsingPost() and then the CSRF handling will be automatic. I think Claude screwed up on this one.

[somethingwithproof]

Understood -- will replace the native confirm() with a jQuery UI dialog to match Cacti conventions.

[somethingwithproof]

Replaced confirm() with a jQuery UI dialog matching the displayDialog() pattern from plugins.php.