<HTML>
<font style="FONT-SIZE: 10pt; FONT-FAMILY: tahoma">
<div>
</div>
<div>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.
<br />
</div>
<div>
</div>
<div>jt
<br />
</div>
<div>
<br />
</div></font>
<br />
<blockquote style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px;
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">-----Original
Message-----
<br />From: Greg Beeley <Greg.Beeley@lightsys.org>
<br />To: SC-L@securecoding.org
<br />Cc: "Steven M. Christey" <coley@linus.mitre.org>
<br />Date: Tue, 13 Jan 2009 16:41:34 -0800
<br />Subject: Re: [SC-L] Some Interesting Topics arising from the
SANS/CWE Top 25
<br />
<br />
<div style="FONT-FAMILY: monospace, courier new, courier">Steve I agree
with you on this one. Both input validation and output encoding
<br />are countermeasures to the same basic problem -- that some of the
parts of
<br />your string of data may get treated as control structures instead
of just as
<br />data. For the purpose of this email I'm using a definition
of "input
<br />validation" as sanitizing/restricting data at its entry to a
program, and
<br />"encoding" as the generation of any string in any format other
than straight
<br />binary-safe data. (obviously in many cases you will have a
more complex
<br />architecture with individual modules/classes also doing their own
"input
<br />validation" too).
<br />
<br />Having both countermeasures in place is a belt-and-suspenders
perspective
<br />which is healthy.
<br />
<br />However, input validation is primarily tied to business
requirements (what
<br />characters are required in the data field), and output encoding is
tied to a
<br />technical knowledge of the output format being used (whether HTML,
SQL, a
<br />shell command, CSV data, text for an eval() call, a UTF-8 string,
etc.).
<br />
<br />The only upside to relying primarily on input validation is that
it gives a
<br />sort of "perimeter protection", a firewall of sorts to the data
coming in that
<br />tends to protect all of the code "behind the firewall". But
it necessarily is
<br />not likely to be a very "smart" firewall.
<br />
<br />One big problem to relying primarily on input validation is that
input
<br />validation can be very far structurally removed from the point
that causes the
<br />trouble -- the injection/encoding point. In fact, the
programmer doing the
<br />input processing may have no knowledge of how the data may be
encoded later,
<br />and in fact the encodings needed may change with time as well.
Proper output
<br />encoding puts the countermeasure in the same place as the
knowledge of the
<br />output format, and puts the responsibility where the expertise is.
It also
<br />makes the code much easier to audit, as you can tell easily that
the encoding
<br />process isn't vulnerable without having to trace the route of
every single
<br />encoded data item through the code and back up to its entry point
into the
<br />program (of course for thorough auditing you'd do that anyhow but
for purposes
<br />other than just that one encoding point).
<br />
<br />A second big problem - as mentioned - is that input validation
relies on
<br />business requirements -- and you can't guarantee that the business
<br />requirements won't require you to permit "troublesome" characters
in the data
<br />field, as in the example you gave.
<br />
<br />- Greg
<br />
<br />Steven M. Christey wrote:
<br />> For example, is SQL injection strictly an input
validation
<br />> vulnerability, or output
sanitization/validation/encoding or whatever
<br />> you want to call it? In a database, the name
"O'Reilly" may pass your
<br />> input validation step, but you need to properly
quote it before sending
<br />> messages to the database. And the actual
database platform itself has
<br />> no domain model to "validate" whether the
incoming query is consistent
<br />> with business logic. My personal thinking,
which seems reflected by
<br />> many web application people, is that many
injection issues are related
<br />> to encoding at their core, and the role of input
validation is more
<br />> defense-in-depth (WITH RESPECT TO INJECTION
ONLY). Yet smart people
<br />> insist that it's still input validation, even
when presented with the
<br />> example I gave. So So what's the
perspective difference that's causing
<br />> the disconnect?
<br />_______________________________________________
<br />Secure Coding mailing list (SC-L) SC-L@securecoding.org
<br />List information, subscriptions, etc - <a
href="http://krvw.com/mailman/listinfo/sc-l" target="_blank">
http://krvw.com/mailman/listinfo/sc-l</a>
<br />List charter available at - <a
href="http://www.securecoding.org/list/charter.php" target="_blank">
http://www.securecoding.org/list/charter.php</a>
<br />SC-L is hosted and moderated by KRvW Associates, LLC (<a
href="http://www.KRvW.com" target="_blank">http://www.KRvW.com</a>)
<br />as a free, non-commercial service to the software security
community.
<br />_______________________________________________
<br />
</div>
</blockquote>
</HTML>