hardening: enforce POST+CSRF for purge syslog devices utility

[somethingwithproof]

Summary

Enforces POST and CSRF validation before the purge utility can delete unused Syslog host records.

Security behavior

• Non-POST requests are logged and rejected.
• Invalid CSRF tokens are logged and rejected.
• If the CSRF helper is unavailable, the action intentionally fails closed: it logs and rejects the request rather than attempting an unsafe manual token fallback.
• User-facing errors remain generic; logs retain the diagnostic reason.
• The confirmation dialog posts the Cacti CSRF token and uses script-context-safe JSON encoding.

Validation

• PHP syntax checks
• tests/regression/issue259_csrf_purge_test.php

Compatibility

Uses existing Cacti plugin conventions and PHP 7.4-compatible syntax.

[Copilot]

Pull request overview

This PR hardens the Syslog plugin’s destructive purge_syslog_hosts utilities action to mitigate CSRF risk by requiring a CSRF-protected POST, and updates the UI flow to submit a POST (instead of a GET link). It also adds a regression script to guard against reintroducing the insecure behavior.

Changes:

• Enforce POST and validate CSRF via csrf_check(false) before executing the purge deletes.
• Replace the utilities GET link with a jQuery UI confirmation dialog that submits a POST including __csrf_magic.
• Add a regression script asserting the hardening behavior and related UI/encoding expectations.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
setup.php	Adds POST+CSRF enforcement for purge action; replaces purge link with a dialog-driven POST flow including CSRF token.
tests/regression/issue259_csrf_purge_test.php	Adds a regression script that scans setup.php for required hardening snippets and safe UI/JS encoding patterns.

[somethingwithproof]

@TheWitness could you take a look? This is the re-opened CSRF+POST hardening for the purge devices utility (original #265), now rebased onto develop. All merge conflicts resolved.

[TheWitness]

That whole json_encode is it really necessary if you are using the __esc() function? If so, we need simplify it in code. Something a big simpler. Some thing like:

<?php print json_safe(__('Devices Selected', 'syslog')); ?>

[somethingwithproof]

Renamed to syslog_json_safe().

On whether the json_encode is needed given __esc(): it is, but only inside the <script> block. __esc() HTML-escapes, and a browser does not HTML-decode inside a script element, so the entities would render literally and a </script> in the value would still break out. The value= attribute and the <p> text still use __esc(), which is correct for HTML context.

Also in this push: the purge post and its redirects now carry header=false following setup.php:1100, the regression test drives the guard against stubs instead of grepping source, issue#259 is in the changelog, and the nav bar encoding work moved off this branch.

Addressed in the syslog_json_safe() helper, used as syslog_json_safe(__('Devices Selected', 'syslog')).