Hi Lester,
On Wed, Aug 17, 2016 at 5:08 PM, Lester Caine <les...@lsces.co.uk> wrote:
> On 17/08/16 03:59, Yasuo Ohgaki wrote:
>> <?php
>> require_once('my_exception_error_handler.php');
> Actually load framework ... and that is the first can of worms?
>
>> require_once('my_input_spec_def_for_this_file.php');
> THIS is my sticking point ...
> What it needs to load is the rules for all of fields that were in the
> page build. For simple forms that is fine, but it does not scale. For
> more complex form it has to scan the input array and build a list of
> keys ... why not carry out checks while doing that scan? Makes building
> an array of rules pointless, just use the individual rules ... except we
> do not know where to get them.
Almost all inputs for a request has fixed set of input that is defined by
application specification.
Your example is special case. You can choose whatever method fits
your needs and requirements.
>
>> // Validate general requirement that cannot covered by filter_requrie*()
>> validate_inputs();
>> // These are came from this RFC. Validate inputs.
>> // What's to validate is design decision, but validating them all is the
>> // best way.
>> filter_require_var_array($_GET, $get_spec);
>> filter_require_var_array($_POST, $post_spec);
>> filter_require_var_array($_COOKIE, $cookie_spec);
>> filter_require_var_array($_SERVER, $server_spec);
> I have less of a problem with the STATIC stuff covered here EXCEPT that
> would be handled as part of loading the framework and include checking
> what state of handling the form you ARE at. In my case the session has
> elements of handling multiple page forms.
>
>> session_start(['use_csrf_protection'=>1]); // There is RFC for this.
>>
>> function check_user_input_error($today) {
>> if (strtotime($today) != date('Ymd')) {
>> $err_msg[] = 'You have entered invalid date. '. $today;
>> return $err_msg;
>> }
>> }
>
> I will not waste time going through your long discussion on handling
> dates it's the bain of my life! Especially when you get given 12/8/2016
> and have no idea if it is August or December! So forms use date pickers
I'm lost. The contract between client and server is "$today must have
'YYYYMMDD' format".
> and browser validation. And the "'You have entered invalid date. '.
> $today;" forms part of the set of rules used to build the form. Validate
> that christening date is later than birth date has a suitable error
> message as part of that rule set. Now cross checking those rules at this
> stage is probably necessary but only if some hacker is trying to be
> cleaver? But in my case business rules can be cross checked in the
The design I'm presenting does not handle errors that has to display
errors message to users.
> database ... apps other than PHP may also be accessing it ( think
> pigging phone apps :( ) ... so the same rules are needed in the database
> business logic. And that is why populating the PHP rules data from the
> database schema makes sense.
It's the same input validation method as Rails. It works mostly, but it
does not sometimes.
Mass Assignment is one example.
(It's the same vulnerability as register_globals=On.
Difference is whether attack target is program variable or database field.
There is mitigation called strong parameters that prevents unwanted
database field updates.)
[CVE-2016-2098] Possible remote code execution vulnerability in Action Pack
https://groups.google.com/forum/#!topic/rubyonrails-security/ly-IH-fxr_Q
(It's "ID" validation oops! "ID" was used w/o validation and resulted
in arbitrary code execution.)
These fatal vulnerabilities could be prevented if Rails adopt the input
validation method described in the RFC.
Validations in model has issues:
- Security model is based on RDB table definitions. Input data that
are not stored in RDB tends to be used without validation.
- Validation is performed when data is stored into RDB. Validation
could be too late to be useful.
- Since there is no validation in controller, it tends to allow
redirection to other systems without parameter validations. (SSRF)
- Since security model is strongly tied to RDB, validation rule tends
to be weak. e.g. Defines only "require"(=NOT NULL) and don't care the
contents.
- Model without RDB tends to be weaker/have issues because validation
rules for RDB tables may not be suitable to the task implemented by
the model.
Even though it has issues, validations in model works. However, it
does not work well if you try to validate "all inputs" from outside. For
instance, validating browser request headers and/or environment
variables in ActiveRecord does not make sense.
Rails security model is not optimized for security but for ease of use.
(The DRY - Don't Repeat Yourself) It works well for many apps, so it's
Ok to choose this security model. I'm presenting security optimized
input validation design. Security has tradeoff relation to cost and ease
of use. No wonder that you feel more burden for adopting more secure
way.
>
>> Simple web forms should be able to be written by PHP core feature
>> only. IMHO.
>
> Just how many versions of 'login' or 'register' pages exist and all have
> checks for valid username, password and email. And all use different
> styles of managing the rules.
>
>> It's impossible to teach beginners how to write code for input validations.
>> As a result, the most important security feature, input validation, is
>> omitted in beginner courses/examples/etc.
>>
>> It's great for beginners to understand what's going on Web apps and
>> what developers should do. It's useful for small web service that
>> requires the best performance possible as well.
>
> We are on the same book, just coming at this from different ends. It's
> that 'my_input_spec_def_for_this_file.php' which is the problem starting
> with just where you get the set of rules from and not having a simple
> beginner friendly method of adding those rules to a variable. There are
> hundreds of legacy examples of how to do a login form, and the vast
> majority use styles of programming that start a user down the wrong path
> from day one ... so can we agree on something simple and easily
> expandable? filter_require_var_array($_POST, $post_spec); could then use
> those rules to build the $post_spec array, but why not just use the
> rules direct?
"Direct" means like this?
$mybool = filter_require_var($_POST['mybool'], FILTER_VALIDATE_BOOLEAN);
It's possible write code with filter_var()/filter_requrie_var(). It
requires many lines looks mostly the same.
Anyway, it seems you have strong opinion for your security model. It's
okay to adopt design fits your needs and requirements. For example,
authentication by username & password is weaker than 2 factor
authentication, but it's still acceptable. DbC is excellent way to
build secure and fast apps, but adoption is choice of developers.
Nobody forces you to use "better way". There are many "better way" in fact.
I wouldn't forces you. You are better not to force your "better way" because
it may not be better to others. If requirements/objectives differ, "better way"
changes.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
