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 sanitation, 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.
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
is actually an integer, if not, Cacti will block the the page
function from continuing.
get_filter_request_var('somevariable', 'options') - This version of the function can do all sorts of verification and sanitization.
set_request_var('somevariable', 'somevalue') - This function will set the Cacti request variable superglobal with a value.
Generally speaking, you should never use either
$_POST 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 you Cacti log will include warnings when an unvalidate
variable has been encountered.
The second method of hardening your Cacti application is through the use of prepared SQL statements. When you use prepared SQL statements, the Database API will validate that all variables have been properly escaped making it much more difficult to perform SQL injection attacks on Cacti.
Examples of non-prepared function calls and prepared include:
$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.
$somevalue = db_fetch_cell_prepared('SELECT COUNT(*) FROM host WHERE id = ?', array($somevariable));
Cacti provides an escaping function to reduce the likelihood of XSS vulnerabilities in Cacti leading to expliotation of other Web Sites. Cacti itself has a very restrictive XSS mitigation policy in affect by default, but following proper output escaping minimizes problems.
The following example is how to, and not to escape output:
print "<tr><td>" . $some_variable . "</td></tr>";
Using the print statement above, for values that come from the database can lead to Stored XSS vunerabilities in your code. So, it's better to use the following:
print "<tr><td>" . html_escape($some_variable) . "</td></tr>";
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.