How can we stop the spreading insecure coding examples at training classes, etc.?

[Kevin.Wall at qwest.com (Wall, Kevin)]

First a bit of background and a confession.

The background: I recently attended a local 4 hr
Microsoft training seminar called "Get Connected with the
.NET Framework 2.0 and Visual Studio(c) 2005". However, I
want to clarify that this example is NOT just a Microsoft
issue. It's an industry-wide issue; only the examples I give
are from this most recent Microsoft training seminar. (Actually,
calling it "training" is probably a stretch; it was more like
and advertisement for .NET Framework 3.0 (a.k.a., "Atlas")
and a forthcoming version of Visual Studio, but that's another
gripe. ;-)

The confession: 90% of the examples presented at this training
was in Visual Basic and about 10% was C#. I personally think that
VB is horrid as a programming language (for the most part, I
concur with Dijkstra about anything BASIC-like; see .sig, below),
and so may be causing some bias with my observations.

Anyway, back to the main point. At this training seminar, the
demo code that they showed (which mostly was about Atlas features,
not about .NET Framework 2.0 features) had very little in the way
of proper security checks. This was most notable in the almost
complete absence of authorization checks and proper data
validation checks. Also, most of these quotations below
are actually paraphrases (including my own!), but nevertheless,
I believe they are fairly accurate and hopefully non-biased.

At one point, the speaker asked "what's wrong with this code
fragment" (a demo to upload a file). I said "there's no proper
data validation, so one can use a series of '..\' in the file
name and use it to do directory traversal attacks and overwrite
whatever file the user id running the web server has permissions
to write to." (Of course, that was the "wrong" answer. Their
"proper" answer was that W3C had instituted a max size of 4MB or
so on files that could be uploaded in this manner, but they had a
mechanism to get around it.)

At another point, while Atlas JavaScript gadgets was being demoed,
someone asked if one could use XMLHttpRequest (XHR) to invoke
_any_ URL. The speaker correctly answered "no; only back to the
originating host:port from where the JavaScript was downloaded
from". The questioner then remarked something like "oh, that's too
bad". But instead of explaining why allowing cross-domain requests
is inherently a BAD Thing, the speaker replied "oh, don't worry;
we also provide you with some software [apparently a proxy of
sorts -kww] that Microsoft wrote that you can put on your web
server so your users can call out to any URL that they wish,
so it's not limited to calling just pages on your own site."
"Great, I thought. Why don't you also provide some mechanisms to
automatically insert random XSS and SQL injection vulnerabilities
into your code too." Sigh. 

Now understand, these are only a few recent examples presented
at this training. Over the past few years, I've seen numerous
other lame examples of demo code elsewhere, ranging from symmetric
encryption examples using block ciphers (where it's implied that
you should always just use ECB mode; in fact no other cipher
modes are even mentioned!), to showing how to create a web
service without even mentioning any mechanisms for authentication
or authorization. (Actually, many typically don't even
_recognize_ the NEED for such things.)

Make no mistake in thinking that this poor practice is limited
to Microsoft. At one point or another, we probably have all done
something like this and then just casually mentioned "of course
you need to do X, Y, and Z to make it secure". I understand the
the pedagogical need that example code has to be kept simple.
Usually much of the error code is completely omitted, not just
security-related checks. But most developers have enough sense
of the application-related errors to know they need to add the
application-level error checking; not so for security-related
checks--at least not for your average developer.

Of course the big problem with any poor examples is that this
is just the type of thing that developers who have little security
experience will copy-and-paste into their PRODUCTION code, thus
exposing the vulnerabilities.  And nowadays, it's even made
easier to copy-and-paste this insecure code by either making it
available for download from the Internet or passing it out on a
CD or DVD. Many of us have probably been guilty of that too,
at least once in our lives.

But we need to all recognize that there is no reason that the
demo code that made available for downloading or on a CD needs
to be the exact same code displayed during the training.
(N.B.: I've not yet checked the DVD supplied by Microsoft,
but the instructors said [paraphrase] we would find "the exact
same code were are using in our examples on the DVD".)

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 was so irate after this whole experience, I filled up the
entire comments section of the evaluation form complaining
about this and how it was a tragedy given that other parts
of Microsoft seem to be working so hard to improve security.

But my question is, is that enough? Should I (we) do more, like
complaining to someone higher up in security--in this case,
to someone at Microsoft, perhaps and advocate such as Michael
Howard? And if so, to whom? And what, if anything, can
we do collectively to try to prevent these types of insecure
demos from making their way into the hands of large numbers
of developers? Maybe we are not raising a big enough stink
in this regard.

Okay; thanks for allowing me to vent. I feel better now, a
little...
-kevin
---
Kevin W. Wall           Qwest Information Technology, Inc.
Kevin.Wall at qwest.com Phone: 614.215.4788
"It is practically impossible to teach good programming to
 students that have had a prior exposure to BASIC: as potential
 programmers they are mentally mutilated beyond hope of
 regeneration"
    - Edsger Dijkstra, How do we tell truths that matter?
      http://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498.html


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.