[SC-L] Coding with errors in mind - a solution?

Wed, 30 Aug 2006 12:13:47 -0700

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

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Reed (Aesec)
Sent: Wednesday, August 30, 2006 1:17 PM
To: [email protected]
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: [EMAIL PROTECTED]
Subject: Re: [SC-L] How can we stop the spreading insecure coding
	examples	at training classes, etc.?
To: "Wall, Kevin" <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1

Quoting "Wall, Kevin" <[EMAIL PROTECTED]>:


  
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)
[email protected]
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php

Reply via email to