On Thu, 25 Mar 2010, Yitzchak Schaffer wrote:

> On 3/24/2010 17:43, Joe Hourcle wrote:
>> I know there's a lot of stuff written in it, but *please* don't
>> recommend PHP to beginners.
>> 
>> Yes, you can get a lot of stuff done with it, but I've had way too many
>> incidents where newbie coders didn't check their inputs, and we've had
>> to clean up after them.
>
> Another way of looking at this: part of learning a language is learning its 
> vulnerabilities and how to deal with them.  And how to avoid security holes 
> in web code in general.

Unfortunately, it's not all web code.  Part of the issue is in selecting 
the correct tool for the job.

Case in point --

I've been working for the last year to integrate a new data system into 
our federation.  The system officially hasn't gone live yet, so as the 
institution building the system had replaced their full time DBA with a 
contractor, the contractor decided he was going to replace all of the work 
that the DBA had already done to enable external sites to subscribe to 
collections within the system.

Unfortunately, he did the entire thing in shell, and he's passing around
SQL scripts, applying them to the database without any validation, and 
he's hard-coded assumptions about how directories are laid out and where 
the script has permissions to write.

Needless to say, when you get someone reading stuff from config files with 
*no* taint checking and *no* escaping or even quoting of arguments passed 
to other commands, I have to clean it up.  I even try passing my changes 
back upstream, but I'm told that the contractor has to make the changes 
(and he then picks and chooses which security changes he's going to make 
... then decides to wrap each 'rm' and dozen other commands in functions 
(so I can override what command's being called?), and I now have a shell 
script that's over 1000 lines.  (okay, that's not fair ... his version is 
only 968 lines, it only gets over 1000 when I try to add my corrections to 
it, and it's only 702 lines when you strip out comments and blank lines)

Now, much of it's just plain bad programming -- I mean, would you test to 
see if variables were set BEFORE loading the config file?   Would you run 
through a series of functions where each one required the other one to 
complete without actually testing to see if any of them actually worked?

(and well, one of those functions was the one that removed a tarball that 
took an hour to generate at the server, and the next one report back the 
'success' to the server, so I couldn't get the server to run it again 
without getting someone to correct things manually)

... I probably wouldn't be so hot on the topic, if it hadn't occupied the 
better part of the last month of my life, and all of this last week. 
(well, it seems that scp'ing a file for the subscription manager to 
service to process, and create a tarball response with the contents for 
your database doesn't work too well when the service isn't actually 
running ... but the way it's written you have *no* idea what the status of 
the server is).

...

sorry, I just needed to vent.

Anyway, part of what makes a good programmer is knowing the correct tools 
to use.  (and unfortunately, by definition, any newbie isn't going to have 
enough languages in their toolbox to be able to make a good selection). 
Yes, we always have to deal with determining the 'best' language based on 
what we know, who's going to maintain it, etc, so we sometimes have to go 
with sub-optimal choices.

But much of it's trying to identify what's going to go wrong with what we 
build, and trying to make sure that it doesn't break in spectacularly bad 
ways.[1]  I guess most people don't have the men with guns show up and 
take your servers for forensic analysis when some types of things go 
wrong, which makes me a little more paranoid in my error handling.

But if you put it out there on the internet, someone, sooner or later will 
attempt to abuse it.  It could be link spam on blogs, or usurping a guest 
book program to send spam, or even people claiming that compression 
artifacts in your data are UFOs[2], resulting in DDoS of your servers.
The bad ones are where they find a way to modify your database, add 
something to your filesystem, or give them a shell on your system.


-Joe

[1] http://xkcd.com/327/
[2] http://www.google.com/search?q=disclosure+nasa+sun+2010