Some Interesting Topics arising from the SANS/CWE Top 25

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

On Wed, Jan 14, 2009 at 12:41 AM, Greg Beeley <Greg.Beeley at lightsys.org> wrote:
> Steve I agree with you on this one.  Both input validation and output encoding
> are countermeasures to the same basic problem...

I'd like to offer a different view for your consideration, which is
that input validation and output encoding actually don't have anything
to do with security. Those techniques are essential software building
blocks. While it is true that omission to use these techniques often
causes security issues, that only means such programs are insecure in
addition to being defective. I think that it's inherently wrong to
associate input validation and output encoding with security. Fix the
defects and the security issues will go away. On the other hand, if
you only fix the security issues you may be left with a number of
defects on your hands.

Input validation layers should focus on accepting only valid data (per
business requirements), while code that transmits data across system
boundaries should focus on using the exchange and communication
protocols correctly.

Actually, now that I think about it more, I think we are struggling
with the term input validation because the term has been overloaded.
In the one sense, we are talking about validating user input, which
mostly needs to concern itself with adhering to business requirements.
This meaning is not very important for security, but the other one,
validating data before something is done with it, is. If you take a
web application for example, you would ideally verify that all user
submitted data adheres to your business requirements.

-- 
Ivan Ristic