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. 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. (obviously in many cases you will have a more complex architecture with individual modules/classes also doing their own "input validation" too).
Having both countermeasures in place is a belt-and-suspenders perspective which is healthy. However, input validation is primarily tied to business requirements (what characters are required in the data field), and output encoding is tied to a technical knowledge of the output format being used (whether HTML, SQL, a shell command, CSV data, text for an eval() call, a UTF-8 string, etc.). The only upside to relying primarily on input validation is that it gives a sort of "perimeter protection", a firewall of sorts to the data coming in that tends to protect all of the code "behind the firewall". But it necessarily is not likely to be a very "smart" firewall. One big problem to relying primarily on input validation is that input validation can be very far structurally removed from the point that causes the trouble -- the injection/encoding point. In fact, the programmer doing the input processing may have no knowledge of how the data may be encoded later, and in fact the encodings needed may change with time as well. Proper output encoding puts the countermeasure in the same place as the knowledge of the output format, and puts the responsibility where the expertise is. It also makes the code much easier to audit, as you can tell easily that the encoding process isn't vulnerable without having to trace the route of every single encoded data item through the code and back up to its entry point into the program (of course for thorough auditing you'd do that anyhow but for purposes other than just that one encoding point). A second big problem - as mentioned - is that input validation relies on business requirements -- and you can't guarantee that the business requirements won't require you to permit "troublesome" characters in the data field, as in the example you gave. - Greg Steven M. Christey wrote: > For example, is SQL injection strictly an input validation > vulnerability, or output sanitization/validation/encoding or whatever > you want to call it? In a database, the name "O'Reilly" may pass your > input validation step, but you need to properly quote it before sending > messages to the database. And the actual database platform itself has > no domain model to "validate" whether the incoming query is consistent > with business logic. My personal thinking, which seems reflected by > many web application people, is that many injection issues are related > to encoding at their core, and the role of input validation is more > defense-in-depth (WITH RESPECT TO INJECTION ONLY). Yet smart people > insist that it's still input validation, even when presented with the > example I gave. So So what's the perspective difference that's causing > the disconnect? _______________________________________________ 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. _______________________________________________
