Secure Coding mailing list archives
Some Interesting Topics arising from the SANS/CWE Top 25
From: Greg.Beeley at LightSys.org (Greg Beeley)
Date: Tue, 13 Jan 2009 16:41:34 -0800
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?
Current thread:
- Some Interesting Topics arising from the SANS/CWE Top 25 Steven M. Christey (Jan 12)
- Some Interesting Topics arising from the SANS/CWE Top 25 Greg Beeley (Jan 13)
- Some Interesting Topics arising from the SANS/CWE Top 25 Johan Peeters (Jan 13)
- Some Interesting Topics arising from the SANS/CWE Top 25 Florian Weimer (Jan 14)
- Some Interesting Topics arising from the SANS/CWE Top 25 Johan Peeters (Jan 14)
- Some Interesting Topics arising from the SANS/CWE Top 25 Johan Peeters (Jan 13)
- Some Interesting Topics arising from the SANS/CWE Top 25 Steven M. Christey (Jan 14)
- Some Interesting Topics arising from the SANS/CWE Top 25 Ivan Ristic (Jan 14)
- Some Interesting Topics arising from the SANS/CWE Top 25 Jim Manico (Jan 14)
- Some Interesting Topics arising from the SANS/CWE Top 25 Brian Chess (Jan 14)
- Some Interesting Topics arising from the SANS/CWE Top 25 Ivan Ristic (Jan 15)
- Some Interesting Topics arising from the SANS/CWE Top 25 Greg Beeley (Jan 13)
- Some Interesting Topics arising from the SANS/CWE Top 25 Joe Teff (Jan 15)