php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #56645 additional filterfunctions
Submitted: 2005-11-14 05:25 UTC Modified: 2006-05-08 13:01 UTC
From: traufeisen@php.net Assigned: pajoye (profile)
Status: Closed Package: filter (PECL)
PHP Version: Irrelevant OS: -
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: traufeisen@php.net
New email:
PHP Version: OS:

 

 [2005-11-14 05:25 UTC] traufeisen@php.net
Description:
------------
Assume the following form:

<form method="post" action="index.php">
Name: <input type="text" name="data[name]" /><br />
Email: <input type="text" name="data[email]" /><br />
Age: <input type="text" name="data[age]" /><br />
<input type="submit" />
</form>

So index.php expects an array called "data" with the key "name","email" and "age".
If there are more than these three, there are 2 options:

- unset the unwanted data
- ignore the unwanted data

I think that unsetting is the better way. There is no need to keep "rubbish" in the script.
Additionally "age" should be an integer-value.
Because all POST-Data is of the type "string" some kind of typecasting would be good. And if "age" is not integer, unset it.
Only keep data, that has the expected type.
Also a "trim" for the stringdata sounds good.

My Idea for cleaning up the incoming data is the following.
First define an array-structure like this:

$structure = array      (
                                                "name"  =>      STRING,
                                                "email" =>      STRING,
                                                "age"   =>      INT,
                                        );

Then filter the incoming data.
Assume that $_POST['data'] is:

array(3) {
  ["name"]=>
  string(11) "testname   "
  ["email"]=>
  string(16) "test@example.com"
  ["age"]=>
  string(2) "25"
}


$data   =       filter($_POST['data'],$structure);

So that $data becomes:

array(3) {
  ["name"]=>
  string(8) "testname"
  ["email"]=>
  string(16) "test@example.com"
  ["age"]=>
  int(25)
}

Or assume the following $_POST['data']:

array(5) {
  ["name"]=>
  string(11) "testname   "
  ["email"]=>
  string(16) "test@example.com"
  ["age"]=>
  string(3) "abc"
  ["foo"]=>
  int(235)
  ["bar"]=>
  string(9) "235svfiso"
}

After filtering, $data would be:

array(3) {
  ["name"]=>
  string(8) "testname"
  ["email"]=>
  string(16) "test@example.com"
}

Because "age" does not contain only numbers, it gets unset.
If the data should be trimmed and/or typecast can be specified by a bitmask as a second parameter to the function or so.


The PHP-Skript can now simply check with an "isset" if the incoming data matches those basic rules.


Next Part: XSS
I think that an inputfilter for preventing against XSS is not the best way.
Many users use template-systems and assign variables like this:

$tpl -> assign("placeholder",$value);

An outputfilter would be better.
A function like "xsscleanup" or something like this, which does basically nothing else than calling "htmlentities" or so for each value.
Such a function should work with arrays too.
I know, there are functions like array_map, but most users do not use them :/
Additionally such a xsscleanup-function should handle iterators too, so that $iterator->current() gets escaped too.
The Templatesystem can then simply pass $value through such a filterfunction.


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-11-18 03:21 UTC] derick@php.net
This is typical behavior that belongs in application logic, and this not in the extension. The extension provides you functionality to filter data, not a full flegded way of dealing with forms.
Output filtering should be a feature of your templating system.
 [2006-05-08 13:01 UTC] pierre dot php at gmail dot com
This bug has been fixed in CVS.

In case this was a documentation problem, the fix will show up at the
end of next Sunday (CET) on pecl.php.net.

In case this was a pecl.php.net website problem, the change will show
up on the website in short time.
 
Thank you for the report, and for helping us make PECL better.

See input_get_args. It provides exactly what you asked.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 12:01:31 2024 UTC