On Aug 25, 2009, at 17:35, Benjamin Tomhave wrote:
You don't teach proofs - not really. The elementary and junior high
curriculum generally does not contain anything about proofs
I was talking about college students because that's when I was
properly taught programming. That may no longer be true. But in
maths, I *was* taught how to do proper proofs in high school (from 7th
grade on, when we had Geometry). I may have been unusually lucky.
I again come back to James McGovern's suggestion, which is treating
coding as an art rather than a science. It increasingly makes sense
given the failures up to this point.
The problem then is that every Joe, Dick, and Harry out there who can
get hello world to compile think they're artists. Seriously, unlike
art, programming is usually not a vehicle for one's creative urges,
but a tool to get a job done, as you yourself say. (I hesitate to use
the word "science" as an antonym to "art" here, perhaps "craft" would
be better.)
Unfortunately, security assumptions are rarely written down so I
don't
see how they can be enforced at the language or compiler level.
Here you make a patently bad assumption yourself. It should be
possible
for the compiler to automatically protect against overflows, as an
example.
Sure, for certain languages and certain classes of well-understood
problems, compiler or language support can be engineered. But my point
stands: security assumptions are rarely written down. This is because
they are taken to be self-evident and not in need of explicit
formulation. Also, they depend on the domain. If I express a hospital
drug disbursal system in any of the common general-purpose programming
languages, the assumption that one cannot be a doctor and a nurse at
the same time is usually implicit. I challenge you to develop Java or C
++ support that will capture any flaw in the implementation of this
particular RBAC *without* having to make that assumption explicit.
Safe input validation and output encoding could also be forced
at a given level.
Really? I'd be interested in hearing about such techniques that cannot
be short-cut (which, as you state, is one big factor for security
defects in software).
Best,
Stephan
_______________________________________________
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.
_______________________________________________
