Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12306
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <412A1C79.6070903@apache.org>
Date: Mon, 23 Aug 2004 09:34:01 -0700
User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803)
MIME-Version: 1.0
To: Adam Q <aqsalter@westnet.com.au>
Cc: Derrell.Lipman@UnwiredUniverse.com, internals@lists.php.net
References: <0ADA645E-F4F3-11D8-AC67-0003939D6C78@westnet.com.au> <smaexa4e.fsf@random.internal> <B7C319CE-F50B-11D8-8B89-0003939D6C78@westnet.com.au>
In-Reply-To: <B7C319CE-F50B-11D8-8B89-0003939D6C78@westnet.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] SQLite security
From: sterling@apache.org (Sterling Hughes)

There are a lot of ways being a stupid programmer can give you an 
insecure website.  Saying that just because someone is too stupid to 
properly lock down their data store (put outside the web root, run PHP 
with proper perms, etc.), makes PHP/SQLite themselves insecure, is like 
putting coffee on your lap, driving and blaming McDonalds for your burns.

- eval($_POST['sterling']);

Adam Q wrote:

>
> On 23/08/2004, at 9:22 PM, Derrell.Lipman@UnwiredUniverse.com wrote:
>
>> Adam Q <aqsalter@westnet.com.au> writes:
>>
>>> I think encryption for SQLite is essential for PHP. Without it, it 
>>> makes it
>>> almost useless in a webscripting language.  Suppose you wanted to 
>>> create an
>>> open source, easily portable, file based guestbook in PHP. I would 
>>> never use
>>> SQLLite under the current circumstances... Although I would love to. It
>>> seems like the perfect solution.
>>>
>>> The database needs a password.... otherwise it is just too much of a
>>> security risk.
>>
>>
>> Others have commented on where the database should (or shouldn't) be 
>> located
>> to avoid these problems.  If the server environment is so inadequately
>> maintained as to put database files in locations where they might be
>> downloaded, then I would contend that it would not be a difficult job to
>> manage to download the PHP or other data file which contains the 
>> username
>>
>
> I can see I've touched a nerve here.
> Has nobody d/l PHPNuke, PostNuke, phpMyAdmin, Mambo... On and on the 
> list goes on?
> They all put their DB access data in a file called "config.inc.php" 
> (or something like that). (ie database passwords and general config data)
> But they protect it by including something along these lines:
>
> <?
> //config.inc.php
> if (defined("correct_entry_point")) {
> my_pref[1] = "lots of good stuff";
> }
> ?>
>
> so even if you know where this file is in your web tree e.g.
> http://www.example.com/db_admin/config.inc.php
> all you get when you put it into a web broswer is a blank page.
>
> Is this insecure? Please don't give me a flat yes.
> The answer lies behind a thousand veils of shade.
> phpMyAdmin consistently is in the top 10 projects on sourceforge. Is 
> this method insecure? (yes, they drone) Then why do the phpMyAdmin 
> developers go ahead with it? Because it works. Simple.
> PHPNuke has a community in the hundreds of thousands. Is this method 
> insecure? (yes, yes, yes)
> PostNuke ditto? (yes, yes, yes)
> Mambo too? (yes, yes, yes)
> I've forgotten because there are so many out there on hotscripts.com? 
> (yes, yes, yes)
>
> And finally, imagine if I used an SQLite DB to store this data... But 
> we've been there before.
>
> Thank you for the information regarding the encryption. I don't have 
> the knowledge or skills to include this into PHP 5, but I appreciate 
> the information - for one thing it means I'm not going crazy, other 
> people have had the same idea.
>
> Adam
>