> [...] 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. _______________________________________________ Secure Coding mailing list (SC-L) SC-L@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. _______________________________________________