On Fri, Aug 5, 2016 at 7:03 AM, Lester Caine <les...@lsces.co.uk> wrote:
> On 04/08/16 22:47, Yasuo Ohgaki wrote:
>>> The correct response to a form validation error is to show a message to the
>>> > user with as much detail as possible, not to simply terminate the script
>>> > and
>>> > assume they are trying to attack your application.
>> We are talking about different things.
>> I'll document it clearly in RFC.
>
> But both need to be done at the same time ...
Right and wrong? Both have to be done in a software.
>
> Validating the input data requires that you have a set of rules for each
> variable, and if all are correct then one can process the 'array', but
> if an element fails validation then one needs to handle the error either
> as suspicious, or simply out of range. I repeat that handling the
> complexities of EACH variable of the validation is a package of work in
> it's own right, and trying to handle some aspects via an array function
> does not remove the more obvious need to decide what order to handle
> validation errors on each element, or to return error messages for each
> variable that fails validation. If the element is some attempt to create
> an injection of js or html tags then it should fail validation, but
> equally it may be a valid input as long as it is escaped and stored in a
> correct manor. The complexity of what you plan for your array validation
> elements start with all the same rules applied to a single variable.
Modern softwares are complex enough to handle inputs securely.
Softwares should use "divide and conquer" principle.
Input validation is like assertion that should never happen.
It should be validated(asserted) according to the software input spec and
it should be checked as soon as inputs arrive to the software, and leave
behind mistakes, logical inconsistency, etc.
Validation(assertion) errors are:
- Broken char encoding
- Broken input format. e.g. Broken int/float/bool, strings like hash/id/etc
- Invalid chars in string. i.e. NUL and other control chars
- Too large/small values. e.g. Too long/short string, too large/small
int, float.
- Too few/many inputs. ("Too many inputs" cannot be address by filter
functions, but can be addressed input validation code)
Some of above are need to be addressed by software business logic
on occasions depending on client output, but input validation should
make sure input values validity as much as possible to reduce
software complexity.
After input validation, business logic should take care of the rest.
Input error(user mistake, logical inconsistency) check should be checked
separately by the software as a part of the software business logic.
This way, business logic code can concentrate on jobs that it should
and reduce complexity of input handling.
This is my view of what input validation should do. (and what business
logic should do)
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
