Files
Cactidocumentation/Standards-Security.md
Thomas Vincent 57b8088e13 docs: comprehensive validation audit, Spine poller overhaul, and technical refactor (#229)
* docs: comprehensive audit, Spine poller overhaul, and technical refactor

- Overhaul Spine documentation (Spine.md) with complete end-to-end guide: architecture, prerequisites for modern distros (EL8/9 CRB, Ubuntu 22/24, Debian 11/12, FreeBSD), SUID root permissions, secure spine.conf setup (0640), Web UI configuration (Paths, Poller type, Data Collectors tuning), MySQL max_connections sizing, and troubleshooting.
- Fix broken links and anchors (Hardening, SNMP data queries, Hook API references).
- Fix broken image reference in Sites.md (add-site.JPG -> add-site.png).
- Fix syntax errors in documentation PHP code blocks, including invalid parenthesization, missing SQL execute quotes, and malformed comments in FAQ.
- Fix DevOps installation commands: use config.php.dist, correct systemctl service names for MySQL/MariaDB/PHP-FPM, remove nonexistent php-json, add missing composer install, and correct Debian/Ubuntu systemd environment path.
- Correct grammatical errors, repeated words, and typos across all markdown documents.
- Remove obsolete unreferenced duplicate installation guides.

Signed-off-by: Thomas Vincent <thomasvincent@gmail.com>

* docs: correct reviewed examples and guidance

Signed-off-by: Thomas Vincent <thomasvincent@gmail.com>

* docs: correct guidance that disagrees with the Cacti source

Verified each claim against include/global_arrays.php, lib/auth.php,
lib/functions.php, host_templates.php and the Spine config parser. The
notable ones: api_plugin_safe_exec() does not exist on either branch,
Spine reads DB_Pass rather than DB_Password, and the CDEF special data
source table was missing five entries and renamed four others.

Signed-off-by: Thomas Vincent <thomasvincent@gmail.com>

* docs: wrap Spine prose and fence the connection sizing formula

The formula's bare asterisks rendered as emphasis, dropping the multiplication signs.

Signed-off-by: Thomas Vincent <thomasvincent@gmail.com>

* chore: refresh copyright year in scripts and issue templates

Signed-off-by: Thomas Vincent <thomasvincent@gmail.com>

---------

Signed-off-by: Thomas Vincent <thomasvincent@gmail.com>
2026-09-08 09:41:21 -04:00

114 lines
4.2 KiB
Markdown

# Security
## General Validation
Never trust input regardless of where it is coming from! The responsibility
falls on the library functions to ensure that potentially dangerous input does
not introduce a security hole. Some sort of sanitization, validation, or quoting
must be provided for **all** arguments in a function. This ensures that bad
data does not make its way into an SQL string, a filename, an executable, or
even another function.
## Request Validation
For Plugin Developers, Cacti includes settings to allow you to know when
you are using unvalidated data. They include:
* get_filter_request_var('somevariable') - This function call, by default,
will validate that the variable `$_REQUEST['somevariable']` returned
is actually an integer, if not, Cacti will block the page
function from continuing.
* get_filter_request_var('somevariable', $filter, $options) - The second
argument is a PHP filter constant such as `FILTER_VALIDATE_INT` or
`FILTER_VALIDATE_REGEXP`, and the third is the matching options array.
This form covers the rest of the verification and sanitization cases.
* set_request_var('somevariable', 'somevalue') - This function will set
the Cacti request variable superglobal with a value.
Generally speaking, you should never use `$_GET`, `$_POST` or `$_REQUEST`
directly in your Cacti code. Use the validators. When you do, you can
turn on the Cacti setting `Log Input Validation Issues` when you are
developing, and your Cacti log will include warnings when an invalid
variable has been encountered.
## OS Command Injection
Never pass unsanitized input to shell execution functions (`exec()`,
`shell_exec()`, `system()`, `passthru()`, `popen()`, `proc_open()`). Device
fields, OID strings, community names, and any other user-influenced values
must be treated as untrusted.
Escape every argument with Cacti's `cacti_escapeshellarg()` rather than the
PHP `escapeshellarg()` directly. The Cacti wrapper strips carriage returns
and line feeds, and it quotes correctly on both Unix and Windows, where
`escapeshellarg()` blanks out percent signs that RRDtool format strings need.
Where a whole command string has to be escaped, use `cacti_escapeshellcmd()`.
Neither function is a substitute for validating the value first: resolve
binaries from a fixed path and check arguments against an expected pattern
before the command is built.
## Prepared Statements
The second method of hardening your Cacti application is through the use
of prepared SQL statements. A prepared statement sends the query and the
values separately, so a value can never be parsed as SQL. This removes the
injection risk that string interpolation creates.
Examples of a non-prepared call and its prepared equivalent:
```php
$somevalue = db_fetch_cell("SELECT COUNT(*)
FROM host
WHERE id = $somevariable");
```
In the case above, it would be very easy to exploit Cacti. The example
below is the correct way to protect against attacks.
```php
$somevalue = db_fetch_cell_prepared('SELECT COUNT(*)
FROM host
WHERE id = ?',
array($somevariable));
```
## Output Escaping
Cacti provides an escaping function to reduce the likelihood of XSS
vulnerabilities in Cacti leading to exploitation of other websites.
Cacti itself has a restrictive XSS mitigation policy in effect
by default, but proper output escaping still matters.
The following examples show how, and how not, to escape output:
```php
print "<tr><td>" . $some_variable . "</td></tr>";
```
The print statement above can lead to Stored XSS in your code whenever the
value comes from the database. Use the following instead:
```php
print "<tr><td>" . html_escape($some_variable) . "</td></tr>";
```
## JavaScript Validation
Relying on JavaScript-based validation is nice for instant feedback to the
user, but should not replace validation checking in the PHP code.
If you follow the simple rules above, your Plugin will be much safer
for others to use and will more easily pass internal security and
pen tests.
## See Also
For OS-level hardening controls covering file permissions, web server access
restrictions, PHP-FPM pool settings, SELinux, and AppArmor, see
[Hardening a Cacti Installation](Hardening-Cacti-Installation.md).
---
Copyright (c) 2004-2026 The Cacti Group