Hi Stas, On Thu, Apr 30, 2015 at 2:42 PM, Stanislav Malyshev <smalys...@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 yohg...@ohgaki.net