Secure Coding mailing list archives

Coding with errors in mind - a solution?


From: pmeunier at cerias.purdue.edu (Pascal Meunier)
Date: Wed, 30 Aug 2006 16:46:34 -0400

Worse is when it works in unintended ways without producing an error.  The
code has to detect whenever something doesn't match a white list of expected
program states and inputs.  I think that in example code, the detection is
more important than the subsequent handling because the handling will vary
depending on the exact application requirements and framework.  The
detection is where contracts and correctness are verified, and I'd like to
leave the handling of violations to some "law enforcement" module, so to
speak.

Perhaps a "good enough" approach for teaching would be to raise an exception
(or use assert statements for languages that don't have exceptions) whenever
a problem is detected, and leave it at that.  This way, the handling of the
exception (logging, UI, aftermath, etc...) doesn't bloat the code and
distract from the main subject, yet all unsafe conditions and errors would
be highlighted and caught.  It's not revolutionary, but it's better than
what we have now.  Would it be good enough?  I can picture people deleting
those assert statements that just make their programs crash ;)

Pascal Meunier



On 8/30/06 2:07 PM, "Michael S Hines" <mshines at purdue.edu> wrote:

a simple structure that provides for errors would go a long way...
 
If - then - else - on error
Do - end - on error
Let x = y - on error
Let x = function() on error
etc...    
 
The problem is writing code without thinking of the possible errors that
might arise.   This forces you to think about the consequences of executing
a command...
 
Where 'error' is doing something intelligent when the original command
doesn't work...  
 
Just a brainstorm....... any merit to it?
 
Mike Hines
mshines at purdue.edu

  _____  

From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On Behalf Of Ed Reed (Aesec)
Sent: Wednesday, August 30, 2006 1:17 PM
To: sc-l at securecoding.org
Subject: [SC-L] e: How can we stop the spreading insecure coding examples
at, training classes, etc.?



Message: 1

Date: Tue, 29 Aug 2006 15:48:17 -0400

From: pmeunier at purdue.edu

Subject: Re: [SC-L] How can we stop the spreading insecure coding

examples at training classes, etc.?

To: "Wall, Kevin"  <mailto:Kevin.Wall at qwest.com> <Kevin.Wall at qwest.com>

Cc: SC-L at securecoding.org

Message-ID:  <mailto:1156880897.44f49a01620aa at webmail.purdue.edu>
<1156880897.44f49a01620aa at webmail.purdue.edu>

Content-Type: text/plain; charset=ISO-8859-1



Quoting "Wall, Kevin"  <mailto:Kevin.Wall at qwest.com> <Kevin.Wall at qwest.com>:





  

I think that this practice of leaving out the "security

details" to just make the demo code short and sweet has got

to stop. Or minimally, we have to make the code that people

copy-and-paste from have all the proper security checks even

if we don't cover them in training. If we're lucky, maybe

they won't delete them when the re-use the code.

    



I agree, and would like to extend it: security should be discussed *at the
same

time* that a topic is.  Teaching security in a separate class, like I have
been

doing, reaches only a fraction of the audience, and reinforces an attitude
of

security as an afterthought, or security as an option.  Comments in the code

should explain (or refer to explanations of) why changing or deleting those

lines is a bad idea.



However, I'm afraid that it would irritate students, and make security the
new

"grammar and spelling" for which points are deducted from "perfectly valid

write-ups" (i.e., "it's my ideas that count, not how well I spell").

The same used to be said about unstructured programming examples (computed
gotos, spaghetti code, multiple entry and exit points from functions, etc).
We got past it.

We need a similar revolution in thought with regard to security, and some
one to take the lead on providing clear, crisp examples of coding style that
is more secure by its nature.  I don't have one handy - but that's my wish.

Ed

_______________________________________________
Secure Coding mailing list (SC-L)
SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php




Current thread: