Attachment: Files of default rules
[modsecurity_crs_40_generic_attacks.conf](http://issues.piwik.org/attachments/564/modsecurity_crs_40_generic_attacks.conf)

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.

I’ve rolled the requirements into #530.

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

Thanks

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:
- the matching is not case sensitive (“fopen” and “FOPEN” throw this rule)
- the matching is on substrings (“fopen” and “fopen is evil” throw this rule)
- the matching applies to arg names, arg values, and file names; these are all thrown
– http://example.com/search?q=fopen+example
– http://example.com/myfopenexample.html
– http://example.com/storage?fOpener=1
- if there’s no match on the PHP injection rule, any of the other 20+ rules may apply, e.g.,
– “cfusion_dbconnections_flush” would throw the ColdFusion injection rule even though Piwik doesn’t use ColdFusion

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.