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
