Some Interesting Topics arising from the SANS/CWE Top 25

[Greg.Beeley at LightSys.org (Greg Beeley)]

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?