Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86070
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZK=2hdC5pzGgupDYt6hy8rnjZ-Gk+LciBsyFQN4T4oYw@mail.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>
	<CAGa2bXZAY_9qx9D+K11ApJH9DKzTvxze+=E5=rVhQj_OaGfxGQ@mail.gmail.com>
	<CAGa2bXbYDAzsqA2PqqngtNTpjN2Oq9-q4BNRjxtU85LJ+WMExg@mail.gmail.com>
	<CAObuZdspHZwj0370z3+_iKBcpE2Ki-HrFrS9A+BNBw=d3GAcjg@mail.gmail.com>
	<CAGa2bXZK=2hdC5pzGgupDYt6hy8rnjZ-Gk+LciBsyFQN4T4oYw@mail.gmail.com>
Date: Wed, 29 Apr 2015 23:12:15 -0700
Message-ID: <CAMPTd_AW8-G6TXdjFDEGcf6Jc3wDuUyOVf+Ev7Ay8c8ndLqAww@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01493d122806ef0514eafa27
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: walterp@gmail.com (Walter Parker)

--089e01493d122806ef0514eafa27
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 29, 2015 at 10:50 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Ryan,
>
> On Thu, Apr 30, 2015 at 1:29 PM, Ryan Pallas <derokorian@gmail.com> wrote:
>
> > On Wed, Apr 29, 2015 at 8:37 PM, Yasuo Ohgaki <yohgaki@ohgaki.net>
> wrote:
> >
> >> Hi Rowan,
> >>
> >> On Thu, Apr 30, 2015 at 11:17 AM, Yasuo Ohgaki <yohgaki@ohgaki.net>
> >> wrote:
> >>
> >> >
> >> >>  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.
> >>
> >
> > How is this different than other languages with type hint? For example,
> > Java or C# - if you type hint int you are limited to 32bit. These
> languages
> > have long and bigint respectively to support 64bit, but type hinting int
> > means you cannot have arbitrarily large numbers.
> >
> > To me it sounds like you're trying to solve an application problem but
> > suggesting a change to the language.
> >
> > >
> >> > 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.
> >> >
> >>
> >> I should have mentioned that I'm supposing DBMS like SQLite here.
> >> As we know, SQLite column accepts any value including value beyond 64
> bit
> >> int.
> >>
> > https://www.sqlite.org/datatype3.html
> >> (Those who don't now "Type Affinity", please read the section)
> >>
> >> From your link " The value is a signed integer, stored in 1, 2, 3, 4, 6,
> > or 8 bytes depending on the magnitude of the value." And take a look at
> > http://jakegoulding.com/blog/2011/02/06/sqlite-64-bit-integers/ where
> > numbers larger than the max are converted to real on storage sometimes,
> > depending on the affinity of the storage type chosen but not on math.
> >
>
> As PHP int type hint does not accept huge float as int, it does not matter,
> does it?
>
> <?php
> function foo(int $v) {
>   echo $v;
> }
>
> foo('1.0e+33');
> ?>
>
> Fatal error: Argument 1 passed to foo() must be of the type integer, string
> given, called in - on line 6 and defined in - on line 2
>
>
> SQLite is the most used RDBMS in the world.
> >>
> > I would love to see some empirical data that supports this claim.
> >
>
> You know number of mobile devices? All Android/iPhone have it.
> Use of SQLite is not limited to phone, but almost every embedded device.
>
> It's about PHP was and PHP currently is.
>
> PHP didn't have any issues with huge record ID at all, but it can result
> in DoS not limited to targeted, but including site wide. Bad news for me
> is these DoS could be triggered by upgrade of library/etc that supports
> PHP7 type hints, not the code that I've authored or supervised.
>
> Anyway, too strict "weak" type hint cases problems any external inputs.
> There should be a resolution.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>


And that is relevant how? How many Android phone run PHP applications?

How many embedded devices of this type run PHP? If you are running a 64 bit
DB and a 32 bit PHP, change one to the other size or pay attention to your
sizes. Or stop using code from people that don't care to program correctly.

I'm sure I could find half a dozen metrics to make something else number
one (I'd put flat files at 1, a Mainframe DB at 2, and some PC db at 3).


Or just live with the fact that it not reasonable to expect that the system
will handle all of type checking for you without people having to think how
to refactor code to include type hints.

The resolution is simple, check your data before you hand it to third
parties if you don't trust them. Use unit and integration tests to alert
you for libraries where this might occur.


Walter
-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

--089e01493d122806ef0514eafa27--