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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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 18:01:29 2024 UTC