On Tue, 13 Jan 2009, Greg Beeley wrote: > Steve I agree with you on this one. Both input validation and output > encoding are countermeasures to the same basic problem -- that some of > the parts of your string of data may get treated as control structures > instead of just as data.
Note that I'm only talking about this in light of injection-related issues. Input validation is an important countermeasure for buffer overflows, for example, whereas output encoding isn't. (Unless you want to take the approach that things like strncpy() or safe string libraries are really related to controlling "output" when you process strings from an input buffer to an output buffer, and shellcode is a means of "injection"...) > For the purpose of this email I'm using a definition of "input > validation" as sanitizing/restricting data at its entry to a program, > and "encoding" as the generation of any string in any format other than > straight binary-safe data. This touches on something that I've been a little concerned about, which is the variety of definitions that people have for the same word. We struggle with that in CWE - which is why "output encoding/escaping" is in the CWE name instead of, say, sanitization or validation. I don't think there's necessarily a solution [face it, we're not all going to adopt the same terminology willingly], but it's a problem. - Steve _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
