[kwlug-disc] Security arguments

[Khalid Baheyeldin]

On Tue, Sep 22, 2009 at 6:42 PM, Chris Frey <cdfrey at foursquare.net> wrote:

> 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.
>

What do we have in common here? The human is the weakest link.
Whether it is the programmer that introduced SQL injections, or the
amateur web master who installs insecure software, and never updates
it, or the guy who clicks the attachment that promises a saucy pictures.

Computers are tools, and if you use the tool to shoot yourself in the foot,
then there is no way to protect people from that, other than by getting
educated on them.


>
> 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.
>

I don't think that "better security" was a design goal for scripting
languages.
There were other factors. Yes, it did get rid of buffer overflows, but that
was not intentional, I think, rather a by product.


> 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.
>

SQL injections are not limited to PHP. They can be in any language, C
included.
But because no one uses C much as a web application language, we don't see
that happening much.


> Both problems are due to lack of attention to detail, and the lack of
> using the tools we already have to conquer the fundamentals.
>

Agreed. Again, humans' fault here.


>
> 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.
>
>
One thing we did in Drupal, is have our own db abstraction layer that
when used correctly, would escape all SQL queries and prevent SQL injection.

See here
http://drupal.org/writing-secure-code
And here
http://drupal.org/node/101496

So users are urged to use the Drupal API, and not the PHP/MySQL API
to access the database. If they do that, they are protected from themselves.

That is not fool proof though, they can bypass that layer and go to the PHP
layer, but with some education, most people eventually use the Drupal API.


> Make programming badly hard.
>

I don't think that this should be a goal, not is it effective. Making it
very hard, will make it very expensive too because the pool of qualified
developers will be less.

I think that education is the key here to mitigate all this, not making
programming hard. Another route is open source, were a pool of people look
at the product, not just one or two people who may be not very qualified.

As a related point: Look at the history of computers and you see attempts at
dumbing down the industry that did not work either.

For example, COBOL was supposed to be a way that managers can write their
own reports and bypass pesky developers who never respond in time. It was
supposed to be English like just for that. What was the result: managers
never learned it, and it was developers who used it for business
applications.

The same was proposed for SQL. Rooted in cartesian math, it was given
(again) an English like syntax so, you got it, managers can produce their
own reports. I can only speculate that it was the query from hell on the
production machine that hte manager ran and caused production downtime that
made them abandon forever the concept of managers creating and running
queries. But the result is that SQL was, like COBOL before it, left for
developers.



>
> - Chris
>
>
> _______________________________________________
> kwlug-disc_kwlug.org mailing list
> kwlug-disc_kwlug.org at kwlug.org
> http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org
>



-- 
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
Simplicity is prerequisite for reliability. --  Edsger W.Dijkstra
Simplicity is the ultimate sophistication. --   Leonardo da Vinci
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20090923/741a2b7d/attachment.htm>