Hi Stas, On Thu, Nov 20, 2014 at 4:38 PM, Stanislav Malyshev <smalys...@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: — avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk; — taking or increasing risk in order to pursue an opportunity; — removing the risk source; — changing the likelihood; — changing the consequences; — sharing the risk with another party or parties (including contracts and risk financing); and — retaining the risk by informed choice. Note 2 to entry: Risk treatments that deal with negative consequences are sometimes referred to as “risk 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 (~= 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 yohg...@ohgaki.net
