# Hardened-PHP and variable filtering extensions...

- Thread: https://externals.io/message/14925
- Original archive: https://news-web.php.net/php.internals/14925
- Started by Stefan Esser on 2005-02-14T17:43:06+00:00
- Messages: 2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #14925 — Stefan Esser — 2005-02-14T17:43:06+00:00

URL: https://externals.io/message/14925#14925

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.

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.

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

Stefan Esser

---

## #14943 — Andi Gutmans — 2005-02-15T00:42:17+00:00

URL: https://externals.io/message/14925#14943 · In reply to: #14925

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