Hi! > I think you wrote your JavaScript code to impose certain format for "date", > "phone", "zip", etc. It's not my JavaScript code, but your JavaScript code > that defines output of browser to your PHP web apps.
There are a lot of use cases that don't have Javascript (or browser, for that matter) frontends. Not that it should matter, as browser is not under your code's control, it's under user's control, and you never know on the PHP side if such thing as browser exists at all. > Accept means that allow program to process input data. (continue execution) Then we disagree here. I strongly object to the notion that the program should stop execution at any unexpected data. This is only marginally better than crashing, and is not very helpful behavior. Modern application is expected to handle data in a more intelligent manner. > If your JavaScript date picker uses "YYYYMMDD" format (date like > 20160817) for a date, anything other than "YYYYMMDD" format is > attacker tampered inputs. You keep returning to Javascript. What I am asking you to consider is that we're not talking about Javascript, we are talking about PHP, and PHP has no relation to Javascript date picker. Some apps use Javascript date pickers, true, but there is a whole world of applications that do nothing of the sort. Javascript does not add much to the picture here. > It may be considered "valid input" means expected inputs from _legitimate_ > users. Anything other than "valid input" should not be accepted because > they come from non legitimate users. i.e. attackers. > > - Broken encoding > - CNTRL chars > - Bad format ( YYYYMMDD is the format for this case ) > - Too long or short ( Exactly 8 chars is the length for this case ) > - and so on > > are examples of invalid inputs. I think this has a smell of blacklisting, which is always almost wrong approach to dealing with data filtering/validation. Blacklists almost always lose to whitelists. If you have a whitelist filter that validates the data, you don't need to worry about chars, lengths and such separately. However, there's nothing here that requires the whitelist filter would bring down the app on failure. It should tell the business logic "this string you gave me is not a valid date" and business logic should deal with it. There's nothing special here in encodings, control chars, etc. that I can see that needs any special handling. > It may increase your work, but you'll get less risks in return. I don't see how. I can write intelligent code that produces helpful messages and be the same - in fact, more, see above about whitelisting - robust than blackbox code that explodes on bad inputs. > The input validation only reject invalid input. > > If you use plain <input> for "date", then you should consider any valid > UTF-8 without CNTRL chars up to 100 char or so, not "YYYYMMDD". > (Assuming UTF-8 is the encoding) But why? If I just check for YYYYMMDD I automatically get all invalid UTF-8 etc. rejected, without even thinking about it. > Software design is upto developers. There are many softwares that do > not follow best practices. Nobody enforce to use the validator as I > explains. It's okay to me this is used by only users who need. As I > mentioned, ISO 27000/ISMS requires this kind of validations, not few > users may need this. I'm not sure what ISO says there, but I'm pretty sure ISO does not specify which exactly code you should use to validate your inputs. The objections are not about validating inputs as a concept, nobody would object to that, it's to specific model of doing this that you propose - namely, doing two separate validation passes, doing blacklisting and bailing out on validation failure. At least I would not do input validation in this manner. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
