Re: [RFC] Safe Casting Functions
| From: | Stas Malyshev | Date: | Thu, 20 Nov 2014 16:54:57 +0000 |
| Subject: | Re: [RFC] Safe Casting Functions | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-79043@lists.php.net to get a copy of this message | ||
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 discussing 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.
This is just your personal opinion. Logging is not a security feature,
and if it were, it could be established independently, and should be
anyway since to_* log nothing. So claiming to_* is a security feature is
just wrong - it's like saying fopen() is a security feature 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. Public web sites may ignore
This is right. So your claim that one is more secure than the other is
not correct.
--
Stas Malyshev
smalyshev@gmail.com