mod_security block the stats update when title contain <? ?> characters
Here is rules provides by default (Online those who have a incidence on Piwik.. because they have some many other rules)
+0100 [Access denied with code 501 (phase 2). Pattern match "(?:(?:\b(?:f(?:tp(?:nb)?f?(?:ge|pu)t|get(?:s?s|c)|scanf|write|open|read)|gz(?:(?:encod|writ)e|compress|open|read)|s(?:ession_start|candir)|read(?:(?:gz)?file|dir)|move_uploadedfile|(?:proc|bz)open)|\$_(?:(?:pos|ge)t|session))\b|<\?(?!xml))" at ARGS:title. [id "950013"](test.domain.be/sid#9345328][rid#9601f48][/piwik/piwik.php]) "PHP Injection Attack. Matched signature <<?>" "CRITICAL"
Attachment: Files of default rules
Not an attack vector. The title parameter is currently ignored by the Piwik server. We'll add some additional requirements to #530.
Sorry, but i never say that the message result from a attack.
Mod_security have many source for filtering, and in this case they watch on the url and see the tag.
piwik.php don't use this value, but the url exist, and if the url wasn't encoded, they throw you !
It's not a big change to encode the < and > tag on the title var.
vipsoft, parameters are already encoded using encodeURIComponent() so that wouldn't fix this issue I believe.
To fix this issue, Number please confirm, we should have "special cases" of strings that we blacklist because they would trigger the mod_security warning. The problem is that these special cases are pretty wide.
As a start, Number, I would suggest you come up with list of these strings in a readable format, then we can decide which characters we would like to special encode. Or would there be a JS way of encoding these?
I think, because it's not possible to change every php function to a encoded string, that the solution could be :
encode the <? and ?> tag, if it's encoded, the string into this tag will never be parsed. And they will pass the test.
if, you don't want to do this, could you please just help me to add this replace in the js file ? I'm a newbie on js..
Matt is correct. piwik.js already encodes those tags. '<?' becomes '%3C%3F'. According to the PHP injection SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES, the transformation htmlEntityDecode is used (and not urlDecodeUni or urlDecode, which would convert '%3C%3F' back to '<?').
The only other cause is mod_security's PHP injection rule matching one of the following strings:
"ftp_nb_fget", "ftp_get", "ftp_put", "ftp_nb_put", "ftp_nb_get", "ftp_nb_put", "ftp_fget", "ftp_fput", "fgets", "fgetc", "fscanf", "fwrite", "fopen", "gzencode", "gzwrite", "gzcompress", "gzopen", "gzread", "session_start", "scandir", "readgzfile", "readfile", "readdir", "move_uploaded_file", "proc_open", "bzopen", "$_post", "$_get", "$_session"
However, the mod_security rule is dubious in that:
Number: so, if you'd like to pursue this, there are two options: