[kwlug-disc] Security arguments

[Chris Frey]

On Tue, Sep 22, 2009 at 02:38:04PM -0400, Paul Nijjar wrote:
> I take a pretty different attitude to this. I think that Apache (or
> the LAMP stack in general) can be a lot more proactive about making it
> easier to program well. PHP is notorious for this, in my opinion -- it
> makes it really easy to write insecure code that is prone to stupid
> attacks like MySQL injections and cross-site scripting. There are ways
> to avoid these attacks but you need to know what you are doing, and
> those ways are not taught in beginner PHP tutorials until the final
> chapters. That's stupid. The tools to program web applications more
> securely should be part of the basic programmer's toolkit, and they
> should be easy for newbies to understand and use. 


Very good point.  But I don't think that programming well is easy,
nor can it be made easy without some unforeseen cost.

A better way, in my view, is to make programming badly hard.

In other words, it should be impossible, or it should hurt, to make
mistakes in programming.  But this sort of mentality isn't something
most programmers like.  I think many programmers actively try to
escape such constraints.

Look at the popular languages today.  So many of them are scripting
languages with no compiler at all.  How can it be thought of as an
advance in security to remove the one thing that checks your syntax
with a fine toothed comb?  Programmers today work around such loss
with test frameworks.  It's like climbing a mountain by throwing away
your rope before you begin.  Yes, you're higher at the end, but in my
view, you did it the hard way.

You mention "C [vs.] programming languages that are not insane."  But in
my view, once people stomped out buffer overflows by moving to PHP, they
fell into the same trap of "make it easy" and got SQL injections instead.
Both problems are due to lack of attention to detail, and the lack of
using the tools we already have to conquer the fundamentals.

Fundamentals like:

	- Cleaning up after yourself (not garbage collection).
		This includes memory, files, handles, sockets,
		temporary data, etc.

	- Privilege separation (as you mentioned with unix ID's, etc)

	- Separation of data and code... this continual massaging of
		data into and out of SQL string statements is nuts.

	- Checking as much program logic as possible at compile time
		instead of run time.

The libraries of functions we use are often so ill-designed, slapped
together with little thought, that new programmers in a given language
are sabotaged before they begin.  And these libraries are written that
way because the langage doesn't make it hard to program badly.  In fact,
the easy way is encouarged... throw it away and let something or somebody
else take care of it.

What would happen to the quality of PHP programs if the function
mysql_exec() was removed entirely?  There would be a huge outcry, of course.
But isn't it this kind of function that encourages the average new
programmer to type:

	$sql = "SELECT * FROM " . $table . " WHERE ID = " . $field_num;
	mysql_exec($dbh, $sql);

I do similar things myself (with added escape calls) but it would be
much better if this was made hard by removing such error prone functions
entirely.  Or at least forcing the programmer to create his own wrapper
library before calling them, relegating them as low level functions.

But this is a fantasy, I know.  Mysql_exec() won't disappear any faster
than pointers have in C.  I know both have value to the experienced
programmer, and I would not want them to disappear completely from the
hands of the experienced.

So it's left to each individual programmer to take responsibility for
his own code, and make programming hard for himself: finding the best
way to do a given task, and eliminating repetition.  This takes time,
money, patience, and attention to every detail.

Make programming badly hard.

- Chris