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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
