Darkreading: Secure Coding Certification

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

> [...] White list validation is the answer to everything except the
> difficult choices developers have to make and often get wrong.
> [...]
> (past,present,future) of the data is that single application? How do you
> test the ability for developers to make the best decisions in imperfect
> situations?

I generally teach the developer to both whitelist where the data enters
the application from the user, AND to escape/encode when building a string
that combines both data (of any origin) and control elements (such as a SQL
statement, HTML document, file and pathname, zero-terminated string, etc.).

The first is always done based on the nature of the data (requirements).
The second is done based on the control boundaries and characters with
special meanings (quotes, html special characters, nul terminators,
directory slashes, "..", etc.)  While both are important ("defense in
depth"), in my opinion, the latter is as important, if not more important,
than the first.  This is for several reasons:

    1) as you said, often a character used for a control boundary or
       which has special meaning is needed in the input data in order for
       the application to work;

    2) when I read code, I want to be able to tell at a glance that it has
       a good chance of being secure, so countermeasures should preferably be
       done close to where they matter;

    3) internal changes to the path of data through a program are not at all
       uncommon.  Basing your input-validation (at the point where the data
       enters the application) on the issues that might be present in the
       totality of the data's path through the application is something that
       is very unmaintainable.  And what happens when someone decides after-
       the-fact "we need to allow an apostrophe in that field", and the
       developers have to remember that the field in question eventually ends
       up going into a SQL statement between a pair of quotes?; and

    4) Trusted data can become untrusted in a hurry!

For instance, I've seen a fair bit of PHP code, and the quality varies quite
a bit, as we all know.  If there isn't very consistent use of escaping /
encoding / etc. when building HTML, SQL, cookies, filenames, etc., I worry.
And that is regardless of how much the application tends to "validate the
input data".  I am concerned when an application only uses escaping /
encoding / etc. when the developer thinks it must be necessary, based on
the apparent origin of the data.  Sure, there is a performance tradeoff
for more generous use of escaping/encoding/etc., but in my opinion it is
very much worth it. (there is a price to be paid for performance, and if
performance is a top requirement, the project managers need to factor
in the security implications of tradeoffs like this one).

When I teach this stuff, I tell folks, "don't just code so that it is
secure, but instead code so that others can see relatively easily that
it is secure".

Greg.