Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79034
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.169 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <546D9A6F.8080106@gmail.com>
References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me> <CAGa2bXY4P9dP6rB0-hZ9E5=ALQv+04s157BtwyF7_N3VZV8igA@mail.gmail.com>
 <546D43B3.60708@gmail.com> <CAGa2bXZE9u+nWz2ebdxhMWSnLxheyMcbFGYRy63a9M6Sz6hfXA@mail.gmail.com>
 <546D9A6F.8080106@gmail.com>
Date: Thu, 20 Nov 2014 19:48:21 +0900
Message-ID: <CAGa2bXYA2D4h2+9KD93n4iMoVu-5GAcZyKjwqiXXrqy_d9Fg7Q@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e013a114e98a32b0508481368
Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e013a114e98a32b0508481368
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Stas,

On Thu, Nov 20, 2014 at 4:38 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> > Please refer to CWE/SANS TOP 25, Monster Mitigation especially.
> >
> > http://cwe.mitre.org/top25/#Mitigations
> >
> > and ISO 27000. (I cannot provide link to it, since one should buy the
> > document to read)
>
> Could you please be more specific about how this relevant to this
> specific case? "But an ISO standard and read it whole" is not exactly a
> good argument when discussing the specific issue.
>

I brought up ISO 27000 as the definition of IT security, since there are
many
definition for security. ISO 27000 does not define what "security measure"
is,
but it defines "risk treatment". Most people use ISO 27000's "risk
treatment"
as "security measure" more or less, I believe. ISMS is common now, too.

ISO/IEC 27000:2014(E)
2.79
risk treatment
process (2.61) to modify risk (2.68)

Note 1 to entry: Risk treatment can involve:
=E2=80=94 avoiding the risk by deciding not to start or continue with the a=
ctivity
that gives rise to the risk;
=E2=80=94 taking or increasing risk in order to pursue an opportunity;
=E2=80=94 removing the risk source;
=E2=80=94 changing the likelihood;
=E2=80=94 changing the consequences;
=E2=80=94 sharing the risk with another party or parties (including contrac=
ts and
risk financing); and
=E2=80=94 retaining the risk by informed choice.
Note  2  to entry:  Risk treatments that deal with negative consequences
are sometimes referred to as =E2=80=9Crisk
mitigation", "risk elimination", "risk prevention" and "risk reduction".
Note 3 to entry: Risk treatment can create new risks or modify existing
risks


> Programmer should control over all inputs as the most important security
> > measure.
> > There are two strategies in general.
> >
> >  - Convert inputs to secure values and ignore possible attacks.
> > (Sanitization)
> >  - Validate inputs to reject malformed values and record possible
> > attacks. (Validation and logging)
>
> Thank you, I am aware of what sanitizing and validating input is.
>
> > to_int can be used as validation. It has advantage to record possible
> > attack (or bug). Logging is
> > one of important security feature. Therefore, validation could be said
> > more secure than sanitization.
>
> I don't see how it can be said. Logging by itself is not a security
> feature, and if you need logging, it could be established independently,
> and should be anyway since to_* log nothing. So claiming to_* is a
> security feature by itself is like saying fopen() is a security feature
> by itself because you could use it to open a log file to which you'd
> write security-relevant data.
>

Logging for accounting is important security feature and defined as part of
risk treatment in the ISO standard. So I consider logging related to risk
treatment is security measure.

As CWE/SANS TOP 25's Monster Mitigation says, developers must
control inputs. If there is something wrong in input, it is better to be
recorded for later auditing as it is a part of ISMS requirement.

(int) cannot catch error, but to_int may catch error. Therefore, I think
to_* is good for better security. i.e. Good for more strict input control.

Please note that (int) cast may increase risk, but it is part of risk
treatment (~=3D security measure) as mentioned in "Note 3" of the risk
treatment definition.


> > Which strategy to adopt is that depends on organization/application
> > policy.
>
> Right. So how can one claim one is more secure than the other? Where is
> the lack of security?
>

As I described above, accounting which requires logging is one of security
measure for me.


>
> > (int) works mostly
>
> What you mean by "mostly"? Could you describe the cases where it does
> not work and to_* does?


Cast doesn't allow to log possible attack/bug. Integer cast involves
truncation.
Casting to 32 bit int for 64 bit database ID causes problem, for example.

Anyway, security measure is not only direct risk elimination, but includes
risk mitigation like logging that helps to evaluate incident impacts. i.e.
Auditability of attack/incident is risk, too.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--089e013a114e98a32b0508481368--