D 2010-07-03T11:20:30
L input.php
P 3d154b26ea31f3719c0c2f67ae03cf867d526347
U mario
W 1938
<h2>input.php</h2>
input.php provides object-oriented security wrappers around:
* $_POST
* $_GET
* $_REQUEST
* $_SERVER
* $_COOKIE
It's located in ext/contrib/input.php, and on invokation automatically replaces the plain $_REQUEST arrays with objects.
This **enforces** accessing input and form data through filter functions:
$_REQUEST->name("inputfield")
There are various filter functions provided per default. But ultimately each application should add custom filter functions, whenever specific input strings are to be expected.
To make the transition easier, the input wrappers provide two additional access methods. Becaus reqriting $_REQUEST<nowiki>["var"]</nowiki> to $_REQUEST->int("var") is a lot of typing, it can be reduced to just adding the ->filter call, leaving angle brackets in place:
* $_REQUEST->name<nowiki>["var"]</nowiki>
Another option is the all-objectish access pattern:
* $_REQUEST->name->var
Besides the aforementioned standard method call:
* $_REQUEST->name("var")
== Implementation ==
The internal implementation is rather simple and boils down to:
class input {
function __construct($vars) {
$this->vars = $vars
}
function name($var) {
return preg_replace("/[^\w\d_]+/", "", $this->vars[$var])
}
}
$_REQUEST = new input($_REQUEST)
So it's very simple to add custom filter functions.
Apart from just filtering, it might be appropriate to add logging functions. If specific input data strings are security related, add a custom function. Should a non-standard string be detected, it can be logged. The advantage of the input wrappers is, that this can be done at once central vector. There is no need to spread input validation unreliably through the application anymore.
== Custom filters ==
Should you have custom filter, please post it here.
Z 6cc3b71cef945fbc3a55b86a07365f52