Some Interesting Topics arising from the SANS/CWE Top 25

[joe at joeteff.com (Joe Teff)]

We are still struggling on simple definitions. I frequently hear names like 
"lack of input filtering" and "csrf" referred to as vulnerabilities when in 
reality one is an attack vector and the other an attack. You (correctly in 
my opinion) refer to input validation and encoding as countermeasures. 
Though I cringe a little with your definition of input as it sounds a little 
too user-centric. Input can come from any untrusted source which is not 
limited to a direct person. I find it amazing how encoded data or bound 
variables are used to stuff data into a datastore and then that same data is 
considered trusted when being re-used even by the same application. I do 
agree with your notion that input validation is frequently insufficient as 
it is often necessary to include problematic characters or combinations of 
characters to satisfy the business requirements. 

  
jt 


 


-----Original Message-----
From: Greg Beeley <Greg.Beeley at lightsys.org>
To: SC-L at securecoding.org
Cc: "Steven M. Christey" <coley at linus.mitre.org>
Date: Tue, 13 Jan 2009 16:41:34 -0800
Subject: Re: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25


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 at 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.
_______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20090115/04f93b3b/attachment.html