Hmm... Well, looking through the AjaxSearch code it seems as if there are some queries executed with standard PHP syntax and others that use the MODx dbAPI. And then delving a bit deeper into the MODx dbAPI it looks to me as if it relies on calling the escape method in order to sanitize queries from injection.
So I think for consistency’s sake I would use the escape function from the db object that’s built into MODx, which looks like this:
function escape($s) {
if (function_exists('mysql_real_escape_string') && $this->conn) {
$s = mysql_real_escape_string($s, $this->conn);
} else {
$s = mysql_escape_string($s);
}
return $s;
}
As you can see, this function relies on
mysql_real_escape_string to replace potentially dangerous characters. I would think that this is sufficient to avoid injection attacks, but if not then it would probably be best to add additional character replacement to this function so that the benefits are carried over to all MODx resources that use this method. And it would be ideal to promote the value of using the MODx API and using the escape method among all resource developers (perhaps there should even be a checklist of security and other things to review before submitting a new resource to the repository).
I’m not sure if AjaxSearch is always executed with the MODx API available, so if it is a special case for that reason then it might not be able to use this method exclusively (skimming the code it appears to be written to work without the API).
None of this will be necessary anymore after 0.9.7 with xPDO is released, of course...
