Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79021
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.49 as permitted sender)
Message-ID: <546D9A6F.8080106@gmail.com>
Date: Wed, 19 Nov 2014 23:38:23 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: PHP Internals <internals@lists.php.net>
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>
In-Reply-To: <CAGa2bXZE9u+nWz2ebdxhMWSnLxheyMcbFGYRy63a9M6Sz6hfXA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> 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.

> 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.

> 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?

> (int) works mostly

What you mean by "mostly"? Could you describe the cases where it does
not work and to_* does?
-- 
Stas Malyshev
smalyshev@gmail.com