Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86072
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.179 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <5541C0E0.2080006@gmail.com>
References: <CAGa2bXYzp3XimLXxC+Py2t1DWhCfX8coTdYHzf6zEiKdxA7r8Q@mail.gmail.com>
 <55401F31.9030703@gmail.com> <CAObuZduZBM0GyWJMA1Fd7eCgPE4vFFZrrhpREQ50a4QJhG6Nvg@mail.gmail.com>
 <CAGa2bXar_oXrsPAErNx5BUdkFAy-p8-D0tfhc3pAnDTGBGJJ7Q@mail.gmail.com>
 <55416849.9010808@gmail.com> <CAGa2bXbkCx2Nqb9YBut3id4N=nhjLBGPN8Ucrx7R6mRnGjB2og@mail.gmail.com>
 <5541753D.5050908@gmail.com> <CAGa2bXYk=2TVFv9aeDjVRpgLKFjhYx6YBCpmWo10u-Qv8b0zpg@mail.gmail.com>
 <55419C0C.7020207@gmail.com> <CAGa2bXaPAwFs=2=wHAE615dhyFO_5sUnKV4X2cMVFJM9xoG1wg@mail.gmail.com>
 <5541C0E0.2080006@gmail.com>
Date: Thu, 30 Apr 2015 15:44:30 +0900
Message-ID: <CAGa2bXYf+ZUiV6m47aUGsTc4=cZjNZWN_cFGcw4SXB2MJJGYnA@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Ryan Pallas <derokorian@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113d6c62ed2cea0514eb6f6d
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113d6c62ed2cea0514eb6f6d
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Thu, Apr 30, 2015 at 2:42 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> > "int" Cast is bad. Incorrect "int" type hint worse as it could trigger
> DoS.
>
> I do not see any potential for DoS here. Trying to assign security
> implications so it looks like disagreeing with you jeopardizes security
> is not a good idea. If your code accepts non-numeric data and puts it to
> functions that except integers without validation, it is bad code and
> "numeric" hint would not help here, as unvalidated data can contain
> anything. If unexpected input causes denial of service in your code, it
> is a code architecture problem, which should not be solved by adding
> stuff to PHP.
>

I fully agree that _all_ inputs must be validated before using for any
purpose
and I always suggest users to do that.

Unfortunately, not all users does this and new PHP type hint opens new hole
that security researchers and attackers are interested in.

filter_var() can be used, but it's limited to CPU architecture...
It's one of the reason why I'm proposing Type Affinity like SQLite.
(I won't convert huge int to float, though. Another reason is performance.)


> > It's not all, but the main issue here is 32 bit CPU & PHP int is too
> > small for
> > database record IDs.
>
> Correct way to go there is treating these IDs as strings or objects and
> having code that handles them properly. If they do not fit PHP int, they
> should not be used with functions that expect int.
>

I fully agree that user must not use int/float type hints that exceeds PHP
limits.
That's the reason why I proposed pseudo "numeric" type in first place.


>
> > To maximize compatibility, arbitrarily size of int/float like
> > string/value should be
> > accepted as numeric(or int/float).
>
> No, it should not be, since they are neither int nor float.


I prefer relaxed int/float type hint a lot, but "numeric" can be
alternative.

It's much easier users to advocate "Use numeric type hint for database
record ID/etc", rather than "Use string type hint for database _and_
validate
it's content by yourself".

PHP were weakly typed and too strict type hint creates issue. Weakening
a bit does not harm any, narrowing window to attack. If user needs native
int/float strictly, they should/can use "strict" mode also.

Do you see issues with relaxing?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113d6c62ed2cea0514eb6f6d--