[kwlug-disc] Security arguments

[Khalid Baheyeldin]

On Wed, Sep 23, 2009 at 1:01 PM, Chris Frey <cdfrey at foursquare.net> wrote:

> On Wed, Sep 23, 2009 at 10:13:51AM -0400, Khalid Baheyeldin wrote:
> > On Tue, Sep 22, 2009 at 6:42 PM, Chris Frey <cdfrey at foursquare.net>
> wrote:
> > > 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.
>
> Slightly rephrased for clarity:  Make bad programming hard.
> Good programming shouldn't be hard, but it is often harder than bad
> programming.
>

Re-phrased like this, I fully agree.

> 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.
>
> Yes, that's the kind of thing I'm talking about, thanks.  For a programmer
> who knows SQL but not PHP, mysql_exec() is easier, but "bad".  If that
> function didn't exist, then learning the good way would come first.
>
> It would be better if the API above didn't need a warning at the top
> of the web page asking users not to concat strings for their SQL, though.
>

Actually, the "Drupal way" is less work than the "directly call MySQL way".
For example, you don't have to know what the database name, user name
and password are, nor do you have to connect to the database explicitly.
It is all done for you under the hood.

That does not stop someone from using the API in an unsafe way, e.g.

This is the advocated and safe way, using placeholders that are escaped by
the API:

db_query("SELECT * from {node} WHERE nid = %d", $_GET['nid']);

A PHP-only programmer would do it the way he always did by concatenating
things:

db_query("SELECT * from {node} WHERE nid = " . $_GET['nid']);

Which is unsafe.

So, education is the key here, learn the API and you will be safer.
Also, if your code is contributed and in the CVS repository, more eyes will
see it and scrutinize it, and hopefully discover bugs.


> For example, the ODBC API has two ways to access the database.  One is
> string based, which is easy to get working, and the other is API based,
> using column binding, which is much safer, much faster, and much harder
> to use the first time.
>
> ODBC (and PHP too) could be made much safer by removing the simple string
> method, and adding exceptions if any data was found in the raw SQL
> statements.  This would force users of the API to use the column binding
> method, making SQL data access safe.  And since the API is hard to use,
> it would likely encourage helper APIs to make column binding easier.
>
> Eventually we'd have the best of both worlds: safe and easy.
>

Yes, agreed. And PHP is slowly moving in that direction. For example,
register
globals and all that were enabled by default, now they are not.

The issue is backward compatibility, applications will break, so it is done
slowly.
PHP 5 is vastly superior to PHP 4 on many aspects, and security is one of
them.
But it will take a couple of versions before it "gets there".

-- 
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/c8f0458b/attachment.htm>