default option ignored when object passed to int filter

Bug #73054 default option ignored when object passed to int filter
Submitted: 2016-09-09 08:46 UTC Modified: 2020-06-08 14:21 UTC
From: dormilich at netscape dot net Assigned: cmb (profile)
Status: Closed Package: Filter related
PHP Version: 5.6.25 OS: Mac OS X 10.11.6
Private report: No CVE-ID: None

 [2016-09-09 08:46 UTC] dormilich at netscape dot net

Description:
------------
When any object is passed through filter_var() with the FILTER_VALIDATE_INT filter and a default option the result is always boolean false instead of the default value. 

Second, the FILTER_NULL_ON_FAILURE flag also shows no effect on passed objects.

Test script:
---------------
<?php
$id = filter_var(new stdClass, FILTER_VALIDATE_INT, [
    'options' => ['default' => 2],
]);
var_dump($id);

Expected result:
----------------
int(2)

Actual result:
--------------
bool(false)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

 [2016-09-09 10:23 UTC] cmb@php.net

-Status: Open +Status: Analyzed -Assigned To: +Assigned To: cmb

 [2016-09-09 10:23 UTC] cmb@php.net

I can confirm both issues: <https://3v4l.org/mAtsv> and
<https://3v4l.org/qEUtH>.

The first issue has been introduced with the fix for bug #49274,
where the function bails out too early thereby ignoring any
default value.

The second issue is actually a duplicate of bug #67167, which has
been fixed (in this regard) only as of PHP 7. The fix should be
backported to PHP 5.6.

 [2016-09-09 12:52 UTC] cmb@php.net

-Status: Analyzed +Status: Closed

 [2017-06-04 01:38 UTC] yohgaki@php.net

I came across this bug fix bug.

Currently, VALIDATE filter returns default values for _invalid_ parameter value/type.

Sanitizing filter may ignore _invalid_ parameter value/type.
However, validation filter must not ignore _invalid_ parameter and must not use default value. It should treat invalid parameters as error.

BTW, ignoring invalid values is now considered as security vulnerability.
See OWASP TOP 10 2017 edition RC. (A7 Insufficient Attack Protection)

 [2017-06-07 22:10 UTC] yohgaki@php.net

-Status: Closed +Status: Re-Opened -Assigned To: cmb +Assigned To: yohgaki

 [2017-06-07 22:10 UTC] yohgaki@php.net

Thanks, I'm responsible for this then.
New OWASP TOP 10 considers current behavior as vulnerability.
I'll submit change proposal.

 [2017-06-07 22:45 UTC] yohgaki@php.net

I've proposed fix already.
https://wiki.php.net/rfc/add_validate_functions_to_filter
The patch behaves as it should. This RFC is declined, though.

I shall propose the RFC again, since current filter module lacks the most important filter/validation. i.e. String filter/validation.

We may be better to have distinguished API for validation and sanitizing. i.e. New module and new API for these.

 [2017-10-24 03:07 UTC] kalle@php.net

-Status: Re-Opened +Status: Assigned

 [2020-06-08 14:21 UTC] cmb@php.net

-Status: Assigned +Status: Closed -Assigned To: yohgaki +Assigned To: cmb

 [2020-06-08 14:21 UTC] cmb@php.net

This bug has already been listed in the changelog as being
resolved.  It made no sense to re-open it.