On 02 Feb 2016, at 09:25, Christian Folini <christian.fol...@netnea.com> wrote: > > Like the previous post on 950907 / 932100, this is controversial because > of possible false positives due to a data file with strings: > https://raw.githubusercontent.com/SpiderLabs/owasp-modsecurity-crs/v3.0.0-rc1/rules/php-function-names.data > https://raw.githubusercontent.com/SpiderLabs/owasp-modsecurity-crs/v3.0.0-rc1/rules/php-config-directives.data > > Could these files be split in the manner explained in the message > before? > > After all, this rule scans input against strings like > dl, eval, exec, from, precision.
I would advocate the same separation as in my previous post re os-commands. But we need a little more firepower for PHP in my opinion. A detailed approach could go like this... 1) Have the user indicate with setvar if they want to protect PHP, and predicate the rules on that. All the non PHP shops will be solved from FP instantly! 2) We need to review the current data file: - I’m missing some stuff there that I see in the wild every day such as: gzinflate, gzdecode, gzuncompress, strrev, zlib_decode… - I also see in some cases the parenthesis is added, like: /file(/ and /assert(/. This seems easy to evade. In PHP, calling “assert ($foo)” or “assert\t\t\t($foo)” is just as valid. In this case, it was probably done because those terms lead to FP. If so, we might move super common terms with relatively low attacker interest, like assert, to the paranoid list. But, in any case they should become more robust regexps like “\bfile\s*(“. 3) Separate the data file. Start with a small “php-commands-critical.data” list. This should contain the usual suspects used for: - obfuscation: base64_decode, gzdecode, etc... - execution: passthru, proc_open, shell_exec, call_user_func, require_once, include_once... - IO: file_get_contents, file_put_contents, fopen, fwrite... - environment inspection and setting: error_reporting, function_exists, ini_set, auto_prepend_file, sys_get_temp_dir... If any of those strings is present, it’s certainly an attack, except for that single person who runs a PHP-related wiki. The list should only contain the real red flags, don’t try to cleverly prevent FP using complex regexps, and cannot contain any common English words (so unfortunately “require” and “include” are off limits...) 4) Other functions could go in “php-commands-functions.data”. This list would be small and contain only *proper functions* having PHP syntax “function()” and have names often used in natural text. To prevent FP we look for the parenthesis. Let’s take example “system”, this is often found in natural text, but an attacker wants to do “system(“ so they need parentheses and a word boundary at the start. So a regexp might look like "\bsystem\s*\(“. Because we have the regexp, FP is lowered. It would still match stuff like “F*ck the system (yeah yeah)” 5) Other PHP related terms could stay in “php-commands-common.data”. This would list the PHP commands and terms of lesser interest. 6) We’ll have to review if there are terms which are so common in natural text that they’ll have to be moved to “php-commands-paranoid.data”. I think this list might be as small as possible. Maybe stuff like “dl”, “require”, “include”. It’s still likely to produce FP... 7) String matching for PHP functions is not powerful enough. We need generic rules that prevent PHP evasion. I don’t remember seeing this in the wild, but an easy way to evade textual signature matches would be PHP variable functions (http://php.net/manual/en/functions.variable-functions.php). For instance, you can do the following to get around the CRS: $aB_4c = 'fil' . 'e_get' . '_contents'; $aB_4c('...'); So we want a generic signature to detect variable function call syntax. Fortunately its syntax is very uncommon in natural text, so I’d advocate putting this rule in normal mode. Anyway my €0.02 or maybe a bit more :) _______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
