I like the ideas. The first thing I’d note is that individuals are free to exclude or remove entire files so as long as the PHP file is named REQUEST-XYZ-PHP-XYZ people running ASP should get this hint (hopefully) this is why we name them in this way. In terms of splitting the files, I most certainly agree with the ‘critical’. Again I caution against splitting data files TOO finely as it will get confusing to support your own instance but this is just a minor issue. As for those parenthesis. You are right and this is actually my fault. I added them to prevent false positives being reported commonly on Cpanel.
On 2/7/16, 8:58 AM, "owasp-modsecurity-core-rule-set-boun...@lists.owasp.org on behalf of Walter Hop" <owasp-modsecurity-core-rule-set-boun...@lists.owasp.org on behalf of mod...@spam.lifeforms.nl> wrote: >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: >> >>http://scanmail.trustwave.com/?c=4062&d=7tO31v4ao2_NNeZ84J8wNSWydu00_AAPk >>vSmewhU_w&s=5&u=https%3a%2f%2fraw%2egithubusercontent%2ecom%2fSpiderLabs% >>2fowasp-modsecurity-crs%2fv3%2e0%2e0-rc1%2frules%2fphp-function-names%2ed >>ata >> >>http://scanmail.trustwave.com/?c=4062&d=7tO31v4ao2_NNeZ84J8wNSWydu00_AAPk >>qKjKQ1VqQ&s=5&u=https%3a%2f%2fraw%2egithubusercontent%2ecom%2fSpiderLabs% >>2fowasp-modsecurity-crs%2fv3%2e0%2e0-rc1%2frules%2fphp-config-directives% >>2edata >> >> 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://scanmail.trustwave.com/?c=4062&d=7tO31v4ao2_NNeZ84J8wNSWydu00_AAPk >vCjeQMDpQ&s=5&u=http%3a%2f%2fphp%2enet%2fmanual%2fen%2ffunctions%2evariabl >e-functions%2ephp%29 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 >http://scanmail.trustwave.com/?c=4062&d=7tO31v4ao2_NNeZ84J8wNSWydu00_AAPkq >emcgoEpA&s=5&u=https%3a%2f%2flists%2eowasp%2eorg%2fmailman%2flistinfo%2fow >asp-modsecurity-core-rule-set ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. _______________________________________________ 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
