php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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
Automatic comment on behalf of cmbecker69@gmx.de
Revision: http://git.php.net/?p=php-src.git;a=commit;h=23e721fc9303dd7423f989f6ff360cdff74aeca1
Log: Fix #73054: default option ignored when object passed to int filter
 [2016-09-09 12:52 UTC] cmb@php.net
-Status: Analyzed +Status: Closed
 [2016-10-17 10:08 UTC] bwoebi@php.net
Automatic comment on behalf of cmbecker69@gmx.de
Revision: http://git.php.net/?p=php-src.git;a=commit;h=23e721fc9303dd7423f989f6ff360cdff74aeca1
Log: Fix #73054: default option ignored when object passed to int filter
 [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-06 15:13 UTC] cmb@php.net
> Currently, VALIDATE filter returns default values for _invalid_
> parameter value/type.

Indeed, and this behavior is documented[1]:

| When default is set to option, default's value is used if value
| is not validated.

This part of the documentation has been committed by you, by the
way, see <http://svn.php.net/viewvc?view=revision&revision=331940>.

Anyhow, this bug fix only changes the behavior with regard to
objects to be consistent with the behavior of otherwise invalid
values, see <https://3v4l.org/IVO7g>, so please open a new ticket
if you think the behavior is erroneous.

[1] <http://php.net/manual/en/filter.filters.validate.php>
 [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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 12:01:31 2024 UTC