Bug #45606 [Com]: FILTER_SANITIZE_NUMBER_INT filters returns "----" as an int

From: Date: Tue, 01 Oct 2013 11:00:25 +0000
Subject: Bug #45606 [Com]: FILTER_SANITIZE_NUMBER_INT filters returns "----" as an int
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-181876@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=45606&edit=1

 ID:                 45606
 Comment by:         jobindcruz at gmail dot com
 Reported by:        php at displague dot com
 Summary:            FILTER_SANITIZE_NUMBER_INT filters returns  "----"
                     as an int
 Status:             Not a bug
 Type:               Bug
 Package:            Filter related
 Operating System:   ubuntu intrepid
 PHP Version:        5.2.6
 Assigned To:        pajoye
 Block user comment: N
 Private report:     N

 New Comment:

Still FILTER_SANITIZE_NUMBER_INT function return Minus(-) Sign


Previous Comments:
------------------------------------------------------------------------
[2008-07-24 12:17:40] lbarnaud@php.net

This result is expected, the documentation for FILTER_SANITIZE_NUMBER_INT says: "Remove all
characters except digits, plus and minus sign".

FILTER_VALIDATE_INT works as you expect: It does not outputs invalid numbers and does range check
using the min/max_range options.




------------------------------------------------------------------------
[2008-07-23 18:46:42] php at displague dot com

I used FILTER_SANITIZE_NUMBER_INT and FILTER_VALIDATE_INT backward in my last comment.

Still, neither filter should ever return '----' as an INT with a minimum value of 1.

------------------------------------------------------------------------
[2008-07-23 18:17:57] php at displague dot com

> sanitize checks only if all characters used in a given
> input can be part of an integer, float, etc

Where does it say that? http://php.net/manual/en/intro.filter.php
From what I could gather from the docs, 
filter_var should return:
 Returns the filtered data, or FALSE if the filter fails. 
and filter_input should return:

Value of the requested variable on success, FALSE if the filter fails, or NULL if the variable_name 
variable is not set. If the flag FILTER_NULL_ON_FAILURE is used, it returns FALSE if the variable is
not set and NULL if the filter fails.

I understand that FILTER_VALIDATE_INT is not as stringent as FILTER_SANITIZE_NUMBER_INT, but given
these input and return combinations:

input   return
x.9      9
x-9     -9
x       ''
-       -
+       +
++      ++
--      --

Then given the string, "<!-- test -->", how is a return value of "----" a
valid INT with a minimum of 1?

I assume a regular expression is behind this filter, and at the very least I expect that it needs to
be updated to only match no more than one "-" or "+" only if it is followed by a
"." or [0-9].  Possibly others depending on localization settings.

It's not much of a validation filter as it exists currently.

------------------------------------------------------------------------
[2008-07-23 16:55:10] pajoye@php.net

The sanitize checks only if all characters used in a given input can be part of an integer, float,
etc. If you like to have a strict validation, use FILTER_VALIDATE_INT (or other validating filters).

------------------------------------------------------------------------
[2008-07-23 16:47:52] php at displague dot com

Description:
------------
In code where I use

filter_input(INPUT_GET, 'id', FILTER_SANITIZE_NUMBER_INT,
array('options'=>array('min_range'=>1)));

a vulnerability scanner tried to supply a value of <!-- test --> to the id parameter of the
page.

This filter statement caused $id=='----'.

Reproduce code:
---------------
$t="<!-- test -->";
$v=filter_var($t, FILTER_SANITIZE_NUMBER_INT,
array('options'=>array('min_range'=>1)));

Expected result:
----------------
$v==false

Actual result:
--------------
$v=='----'


------------------------------------------------------------------------



-- 
Edit this bug report at https://bugs.php.net/bug.php?id=45606&edit=1


Thread (6 messages)

« previous php.bugs (#181876) next »