Best practices vs mitigating risk. Enumerating best practices is much easier and will most likely be the test's theme. White list validation is the answer to everything except the difficult choices developers have to make and often get wrong. Too many times, the white list has to include those pesky little characters that cause all the problems. White listing a phone number, amount, or zip code is easy. White listing people's names, addresses, or comments isn't as easy especially when business requirements or contractual/legal obligations rear their ugly head. How mamy times have you seen prepared statements, stored procedures, or magic quotes be the answer to SQL Injection, yet most want to consider those very same data stores as trusted. How many applications do you know where the only entry/exit point (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?
-----Original Message----- From: Florian Weimer <[EMAIL PROTECTED]> To: "Johan Peeters" <[EMAIL PROTECTED]> Cc: "SC-L@securecoding.org" <SC-L@securecoding.org> Date: Sun, 13 May 2007 10:44:19 +0200 Subject: Re: [SC-L] Darkreading: Secure Coding Certification > * Johan Peeters: > > > I agree that multiple choice alone is inadequate to test the true > > breadth and depth of someone's security knowledge. Having contributed > > a few questions to the SANS pool, I take issue with Gary's article > > when it implies that you can pass the GSSP test while clueless. > > But I guess you can fail it because your views are too refined (and > you take too long to make your choices). After all, there are > different schools of thought when it comes to secure coding and its > methodologies. For instance, summing up buffer overflows or directory > traversals under "input validation" is somewhat debatable. > _______________________________________________ > 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. > _______________________________________________ _______________________________________________ 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. _______________________________________________
