Re: Are bad developer libraries the problem with M$ software?

> those weren't likely to happen. I do feel that much of the problem

I started a webappsec thread on an issue much the same (http://online.securityfocus.com/archive/107/290009/2002-08-29/2002-09-04/1) . I'm surprised it wasn't replicated here.

I'll paste it here in case anyone wants to run with it (it's still a project I'd like to do and I'm not sure how many people on webappsec caught what I was getting at):

--

Sverre Huseby posted a very interesting and well-written dissertation on
sessions to webappsec. Latching onto this, I'd like to propose something
that's been bubbling around in my head for some time now. (If it's already
been mentioned, flame away.)

I think that most on the list would agree that, overall, most web apps are
terribly insecure (XSS is pathetically prevalent). I consider myself a
relatively security-conscious programmer, but I didn't even realize that my
apps were vulnerable until I became curious and looked it up after seeing a
large number of mesasges about it on Bugtraq. I didn't even know it existed;
how could I have been expected to protect my apps from it?

The last book I bought about a language was in my VB phase; I still haven't
read the whole thing. Most of what I learn is gleaned from online tutorials,
sample code, and the formal documentation. Until recently, I had no formal
CS education. Although this might not be the norm in the US, I'm sure that
my situation parallels others'. I can't afford (as a full-time HS student)
to spend $40 on a thick PHP book. So I read what I can online.

I don't recall ever hearing a word of caution about metacharacters, SQL
statement injection, or XSS in my (beginner) sources. I was never told to
escape data before feeding it to the database -- or, much less, escaping
outgoing data. I took example code and tweaked it without much regard for
security. I coded lamely because _I didn't know any better_.

A reactive approach towards securing apps is running in place: new,
oblivious coders will just keep producing more bug-riddled code.

To reach new coders (our next "generation"), we must first fix our own
mistakes: bug-riddled _pedagogies_ that teach bad habits.

I can't say anything about the current state of books; I can be fairly
Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software:
Learn more about Pantek's Technical Support offerings
Place an order for 24/7/365 Technical Support here
Learn more about Pantek, who we are, and what we do
Chat with a Live Operator
Related securityfocus.com Links
bugtraq
certification
focus-bsd
focus-ids
focus-ih
focus-linux
focus-ms
focus-sun
focus-unix-other
focus-virus
forensics
incidents
libnet
linux-secnews
ms-secnews
pen-test
secpapers
secprog
sectools
secureshell
security-basics
securityjobs
sf-news
vuln-dev
webappsec
Request more information about Pantek
certain, though, that few people are going to pick up a book or download a
tutorial branded explicitly as a security text. I know I wouldn't. Why? A
lack of knowledge, yes, but time constraints, too. If I need to learn a new
language and code an app with it in a week, security will hardly even be an
afterthought.

How can this be rectified? Hook them from the start -- there is no reason
that sample code should be insecure. Teach people to use print(escape($foo))
instead of just print. Explain the dangers to them in the early stages: I
thought XSS was trivial at first. Possibly even develop a library of
decently-licensed snippets that can be easily massaged into any tutorial.
This is in no way limited to web apps; the principles I've enumerated apply
to any coding situation.

We need to, as a community, fix this: it's ignorant to berate "clueless"
programmers when they haven't been offered a clue.

--

apl

----- Original Message -----
From: "Alec Kosky" 
To: "Steven M. Christey" 
Cc: 
Sent: Monday, November 18, 2002 3:33 PM
Subject: Re: Are bad developer libraries the problem with M$ software?

snip