<HTML>
<HEAD>
<TITLE>Re: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>> In the one sense, we are talking about validating user input, which<BR>
> mostly needs to concern itself with adhering to business requirements.<BR>
> This meaning is not very important for security, but the other one,<BR>
> validating data before something is done with it, is.<BR>
<BR>
Yes, two forms of validation are required. If you hang around with the compliers crowd for too long, you’ll call them syntax validation and semantic validation.<BR>
Syntax: “the input must be an integer”<BR>
Semantics: “the input must identify an account held in your name.”<BR>
<BR>
It’s often possible and even desirable to perform syntax checking not long after a program accepts its input. You can bottleneck a program and make sure all input runs through a syntax validation layer. Not so with semantic checks. In many cases they are so closely related to the program logic that ripping them out and creating an “semantic validation layer” would essentially double the length of the program and create a maintenance nightmare.<BR>
<BR>
So which form of input validation is security input validation? Both! In most cases you can’t afford to skip either one. Bad or absent syntax checks lead generic kinds of problems like SQL injection. Bad or absent semantic checks lead to problems that are often more specific to the application at hand. <BR>
<BR>
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 (<a href="http://www.amazon.com/dp/0321424778">http://www.amazon.com/dp/0321424778</a>), 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.<BR>
<BR>
Brian<BR>
<BR>
<BR>
On 1/14/09 2:02 PM, "Ivan Ristic" <<a href="ivan.ristic@gmail.com">ivan.ristic@gmail.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>On Wed, Jan 14, 2009 at 12:41 AM, Greg Beeley <<a href="Greg.Beeley@lightsys.org">Greg.Beeley@lightsys.org</a>> wrote:<BR>
> Steve I agree with you on this one. Both input validation and output encoding<BR>
> are countermeasures to the same basic problem...<BR>
<BR>
I'd like to offer a different view for your consideration, which is<BR>
that input validation and output encoding actually don't have anything<BR>
to do with security. Those techniques are essential software building<BR>
blocks. While it is true that omission to use these techniques often<BR>
causes security issues, that only means such programs are insecure in<BR>
addition to being defective. I think that it's inherently wrong to<BR>
associate input validation and output encoding with security. Fix the<BR>
defects and the security issues will go away. On the other hand, if<BR>
you only fix the security issues you may be left with a number of<BR>
defects on your hands.<BR>
<BR>
Input validation layers should focus on accepting only valid data (per<BR>
business requirements), while code that transmits data across system<BR>
boundaries should focus on using the exchange and communication<BR>
protocols correctly.<BR>
<BR>
Actually, now that I think about it more, I think we are struggling<BR>
with the term input validation because the term has been overloaded.<BR>
In the one sense, we are talking about validating user input, which<BR>
mostly needs to concern itself with adhering to business requirements.<BR>
This meaning is not very important for security, but the other one,<BR>
validating data before something is done with it, is. If you take a<BR>
web application for example, you would ideally verify that all user<BR>
submitted data adheres to your business requirements.<BR>
<BR>
--<BR>
Ivan Ristic<BR>
_______________________________________________<BR>
Secure Coding mailing list (SC-L) <a href="SC-L@securecoding.org">SC-L@securecoding.org</a><BR>
List information, subscriptions, etc - <a href="http://krvw.com/mailman/listinfo/sc-l">http://krvw.com/mailman/listinfo/sc-l</a><BR>
List charter available at - <a href="http://www.securecoding.org/list/charter.php">http://www.securecoding.org/list/charter.php</a><BR>
SC-L is hosted and moderated by KRvW Associates, LLC (<a href="http://www.KRvW.com">http://www.KRvW.com</a>)<BR>
as a free, non-commercial service to the software security community.<BR>
_______________________________________________<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>