On Thu, Jan 15, 2009 at 5:25 AM, Brian Chess <br...@fortify.com> wrote: > ... > > There's a lot to say about input validation. Jacob West and I wrote devoted > a full chapter to it in Secure Programming with Static Analysis > (http://www.amazon.com/dp/0321424778), but we found that the material > refused to stay in its cage—input validation got a lot of airtime when we > talked about the Web, when we talked about privileged programs, and then > again when we got around to the litany of common errors in C/C++ programs.
True, but do you have a chapter dedicated to output encoding? I don't mind talking about input validation for as long we spend sufficient time discussing output encoding. The problem is that most people don't. Furthermore, a significant problem is that our terminology is incorrect and misleading. I prefer to use the terms data validation and data transformation to replace input validation and output encoding, respectively. Most people will perceive the words input and output as user-centric, ignoring what goes on within software and ignoring the processes that occur without a direct user action. Once you take these misleading words out, you can focus on component boundaries (rather than on the user-software interaction), and start making sure that data is both transformed and validated whenever it crosses component boundaries. Allow me to quote the first paragraph from the chapter you mentioned: *The most important defensive measure developers can take is to thoroughly validate the input their software receives. Input Validation and Representation is Kingdom #1 because unchecked or improperly checked input is the source of some of the worst vulnerabilities around, including buffer overflow, SQL injection, and a whole host of others. * Now allow me to change the wording slightly: *The most important defensive measure developers can take is to carefully handle the data their software processes. Data validation and transformationis Kingdom #1 because improperly checked or improperly transformed data is the source of the some of the worst vulnerabilities around, including buffer overflow, SQL injection, and a whole host of others. * Similarly, I think the sentence that follows: *Ask your local software security guru to name the single most important thing that developers can do to write secure code, and nine out of ten will tell you, "Never trust input."* Works better as: *Ask your local software security guru to name the single most important thing that developers can do to write secure code, and nine out of ten will tell you, "Never trust data." * Now it's easier to see how "Never trust data" actually translates to "Always validate and transform data". -- Ivan Ristic
_______________________________________________ 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. _______________________________________________
