Has anyone who holds to this taught a beginning level programming
class? Getting students to understand what a loop is can be hard
enough, given limited time. Diving into exploits and buffer overflows
can be much more difficult.
I am sure some things could be put into a basic class, but the ideas
are a bit deeper. Security at the "Hello World!" or Mortgage
Calculator program level seems quite difficult.
This bears some thinking through, but the security risks seem to be:
- Make sure the input amount is in dollars.
- Make sure the term is numeric and within "reasonable" ranges.
- Make sure that interest rate is in the form of XX.XX.
Other things checked for would be
- Proper output.
- Pausing at the right point so the output can be viewed correctly.
I am sure I am missing things, but this should serve as a base.
Where do you inject security there? Sure, you can note the importance
of checking the data, but just because someone checks the input here
doesn't mean they will have a clue on checking the input on a web form
for an SQL injection attempt.
I get students who can't loop to start over, they are certainly not
going to catch that they need to do deeper input inspection,
especially in a completely unrelated topic.
I am probably blowing some smoke here and I may disagree with myself
later, but I think this discussion is worth having.
--
Brad Andrews
RBA Communications
CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI
Quoting Mike Lyman <mlyman-ci...@comcast.net>:
Neil Matatall wrote:
So where does secure coding belong in the curriculum?
Higher Ed? High School?
Undergrad? Grad? Extension?
Secure coding needs to be taught anytime programing is taught.
From my experience in my son's boy scout troop, I'm not sure I'd call it
out as security and confuse middle school/junior high school students
but I'd teach them basics like input validation and bounds checking as
basic good programing. The security aspects can wait until later when
they can better handle several concepts at once.
After that is just needs to be part of the course and called out for
what it is. There is room for stand alone security focused training and
courses but it needs to be drilled in all along the way. I recall my own
computer science instructors telling us *not* to spend time on bells and
whistles and concentrate on the concept the lesson was covering. If the
lesson was on pointers, adding things like error checking and user
friendly features didn't count for anything. I can understand why that
was said but it sends the wrong message and begins the development of
bad habits. That was 20 to 30 years ago and most computer users' idea of
security was locking their car doors but it did set us up for bad
habits. Basics need to be drilled in early and always count for
something even if the lesson is while loops.
--
Mike Lyman
mly...@west-point.org
_______________________________________________
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.
_______________________________________________