Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86056
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.182 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <55418CBE.6050609@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>
 <554176D6.2030007@gmx.de> <CAGa2bXaPjvkFYtkhRM1JisSvxgR0v8adkD_P_zkUng4xfBWFHg@mail.gmail.com>
 <55418CBE.6050609@gmail.com>
Date: Thu, 30 Apr 2015 11:17:17 +0900
Message-ID: <CAGa2bXZAY_9qx9D+K11ApJH9DKzTvxze+=E5=rVhQj_OaGfxGQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01182252565b8c0514e7b416
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e01182252565b8c0514e7b416
Content-Type: text/plain; charset=UTF-8

Hi Rowan,

On Thu, Apr 30, 2015 at 11:00 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 30/04/2015 02:24, Yasuo Ohgaki wrote:
>
>> "Type hints" have never been hints.  The wording is a misnomer.  Try to
>>> pass an int to a parameter declared as array, for instance.
>>>
>>>  I understand how it worked and how it will.
>> "hint" sounds a little misleading. Since we named it already, we may
>> follow
>> the semantics.
>>
>
> Or, since we chose the semantics already, we may consider better names
> (see on-going discussion on PHP-DOC list, for example).


I noticed that.
Type hint became "hint" actually by PHP7 because it convert string/float to
int, for example. IMHO.


>  A fatal error wouldn't constitute a DoS vulnerability, would it?
>>>
>>>  Attacker may inject huge ID value and/or they may simply access
>> web sites to reach 2 billion limit, for example.
>>
>
> That's not a DoS vector unless you've also done something else wrong, it's
> just an embarassing error like many others. A lot of the time, the DB will
> overflow first anyway, because an SQL "int" is signed 32-bit. Hell, YouTube
> had a 32-bit int for number of views until Gangnam Style overflowed it!
>

Not really. Primary key is out of user control almost always. However,
suppose code allows to specify foreign key and code assumes that non
existing foreign key results in search query failure.

Current PHP: Search query failure.
New PHP type hint: Fatal error because foreign key is out of PHP int range.

If user are using type hints everywhere, it may be limited to attackers
seeing fatal errors. If not, attacker can succeed system wide DoS attack by
simple operation.


> Sure, if a user can somehow insert custom data into a BigInt DB column,
> via a 32-bit webserver, without causing the error on the way in, but in
> such a way that other users would end up retrieving that record when they
> tried to access the site, and it was then run through a function with an
> "int" type annotation you'd have a Denial of Service. That's hardly "PHP 7
> broke my website", though.


There are systems that has "32 bit PHP client that queries 64 bit server".
Many IoT devices will stick to 32 bit CPUs.

Current PHP:  Database ID is string and it works for any value.
New PHP type hint: Fatal error for values beyond PHP int range.

There are IoT devices that can be controlled by PHP already. We don't have
to limit ourselves.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e01182252565b8c0514e7b416--