@anonymous-matomo-user opened this Issue on February 25th 2009

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][1]) "PHP Injection Attack. Matched signature <<?>" "CRITICAL"
Keywords: mod_security

@anonymous-matomo-user commented on February 25th 2009

Attachment: Files of default rules

@robocoder commented on February 25th 2009 Contributor

Not an attack vector. The title parameter is currently ignored by the Piwik server. We'll add some additional requirements to #530.

@anonymous-matomo-user commented on February 25th 2009

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.

@robocoder commented on February 25th 2009 Contributor

I've rolled the requirements into #530.

@mattab commented on February 27th 2009 Member

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?

@anonymous-matomo-user commented on March 4th 2009

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..


@robocoder commented on March 14th 2009 Contributor

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",
        "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:

  • rewrite _pk_escape() to convert every character (including alphabetic characters and UTF-8) to %xx equivalents. In the worst case, the constructed URL is 3x longer.
  • rewrite _pk_escape() to use base64 encoding. Worst case URL is 33% longer.
    In either of the above cases, corresponding server changes are necessary. The other alternative is to make Piwik (or piwik.php) an exception to mod_security.
This Issue was closed on July 30th 2009
Powered by GitHub Issue Mirror