Re: Hardened-PHP and variable filtering extensions...

At 06:43 PM 2/14/2005 +0100, Stefan Esser wrote:

Hello, recently there was a discussion on this list about variable filtering within PHP. Because of this discussion I have put a preview of Hardened-PHP 0.3.0 online at hardened-php.net. (This preview does not contain all new features but the variable filtering relevant ones. It adds the following new ini directives: Filtering Directives -------------------- # Global Policy for Request Variables # allow - all not explicitly forbidden contents are allowed # deny - all not explicitly allowed contents are forbidden hphp.request.policy = deny | allow # Global Filter for Request Variables hphp.request.filter = deny|allow /regexpattern/i # Variable Specific Filter hphp.request.varfilter = varname deny|allow /regexpattern/i (The same directives exist variable type specific: hphp.cookie.policy, hphp.post.policy, hphp.get.policy, ...) Limiting Directives ------------------- hphp.XXX.max_vars hphp.XXX.max_name_length hphp.XXX.max_totalname_length hphp.XXX.max_value_length hphp.XXX.max_array_depth hphp.XXX.max_array_index_length where XXX is request/get/post/cookie Fileupload Directives ---------------------

hphp.upload.max_uploads         - maximum number of file uploads per request

hphp.upload.disallow_elf_files - disallow uploaded ELF files hphp.upload.verification_script - call this script to verify uploaded files Additionally the log system was improved Logging Directives ------------------ hphp.log.syslog = loglevels that should be logged through syslog (S_MEMORY is always logged through syslog) hphp.log.syslog.facility = syslog facility hphp.log.syslog.priority = syslog priority hphp.log.sapi = loglevels that should be logged through sapi error log (f.e. apache error log) hphp.log.script = loglevels thath should be logged through the logscript hphp.log.script.name = script for logging (1st param f.e. S_MISC 2nd param: message) loglevel meaning ----------------- S_MEMORY Log memory errors, like carnary violations

S_VARS    Log dropped variables

S_INCLUDE Log malicious includes S_FILES Log malicious fileuploads

S_SQL     Log failed MySQL queries (f.e. someone trying to SQL inject)
S_MISC    Log other attacks (f.e. format string attacks)

PS.1: You see that all filtering directives do drop the variables and do NOT try to remove malicious content. Repairing malicious input is considered bad practise.

Once we have input filtering in PHP, it might be interesting for you to extend that work in your project but I understand you want to provide something ASAP for your user base. Probably some of the things you'd do wouldn't be suitable for the mainstream PHP user base.

PS.2: Anyone interested in suggesting a new name for Hardened-PHP? Obviously the PHP Group does consider Hardened-PHP as violator of the PHP license and demands/wants a name change.

How about Hardened Security for PHP? I guess that's a bit lame though :)

PS.3: Yes some of these feature are similiar in mod_security (with the exception that in Hardened-PHP they actually work)

:) Andi