Some Interesting Topics arising from the SANS/CWE Top 25

[ivan.ristic at gmail.com (Ivan Ristic)]

On Thu, Jan 15, 2009 at 5:25 AM, Brian Chess <brian at fortify.com> wrote:
> ...
>
> There's a lot to say about input validation.  Jacob West and I wrote
devoted
> a full chapter to it in Secure Programming with Static Analysis
> (http://www.amazon.com/dp/0321424778), but we found that the material
> refused to stay in its cage?input validation got a lot of airtime when we
> talked about the Web, when we talked about privileged programs, and then
> again when we got around to the litany of common errors in C/C++ programs.

True, but do you have a chapter dedicated to output encoding? I don't mind
talking about input validation for as long we spend sufficient time
discussing output encoding. The problem is that most people don't.
Furthermore, a significant problem is that our terminology is incorrect and
misleading. I prefer to use the terms data validation and data
transformation to replace input validation and output encoding,
respectively. Most people will perceive the words input and output as
user-centric, ignoring what goes on within software and ignoring the
processes that occur without a direct user action. Once you take these
misleading words out, you can focus on component boundaries (rather than on
the user-software interaction), and start making sure that data is both
transformed and validated whenever it crosses component boundaries.

Allow me to quote the first paragraph from the chapter you mentioned:

*The most important defensive measure developers can take is to thoroughly
validate the input their software receives. Input Validation and
Representation is Kingdom #1 because unchecked or improperly checked input
is the source of some of the worst vulnerabilities around, including buffer
overflow, SQL injection, and a whole host of others.
*

Now allow me to change the wording slightly:

*The most important defensive measure developers can take is to carefully
handle the data their software processes. Data validation and
transformationis Kingdom #1 because improperly
checked or improperly transformed data is the source of the some of the
worst vulnerabilities around, including buffer overflow, SQL injection, and
a whole host of others.
*

Similarly, I think the sentence that follows:

*Ask your local software security guru to name the single most important
thing that developers can do to write secure code, and nine out of ten will
tell you, "Never trust input."*

Works better as:

*Ask your local software security guru to name the single most important
thing that developers can do to write secure code, and nine out of ten will
tell you, "Never trust data."
*

Now it's easier to see how "Never trust data" actually translates to "Always
validate and transform data".

-- 
Ivan Ristic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://krvw.com/pipermail/sc-l/attachments/20090115/271742c9/attachment.html