Everything

php

Home » Project » Newsgroups » php.internals » SQLite security »

SQLite security

php.internals

Adam Q

22 years ago

Dear all,
I feel I may have uncovered a potentially large difficulty for the
adoption of SQLite.

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.

I would like to use an SQLite DB for the prefs for an open source PHP
project, but I can't find any way to be sure the DB file is going to be
secure... Is it possible to password protect a SQLite DB file?

If not, I can't think of one (1) web based application where I would
recommend SQLite.
Maybe for PHP-GTK, but that is not web based (and PHP is used a great
deal for web scripting).

With the current setup, if I include a .htaccess for the DB dir, this
will only work for Apache - not IIS.
I know I can include a warning about how important it is to place the
files outside the HTTP directory tree and .htaccess files are good, but
it is just too easy to download an SQLite DB... I can't really see any
PHP use that would be OK for this really.
if I put the db file "SQLITE.DB" into /www/db
Anybody can d/l it by typing
http://myserver.com/db/SQLITE.DB

I though I might even be able to prevent d/l by naming the DB file with
a "." at the start but it makes do difference.

... and if the project is open source it is just too much of a security
risk as everybody knows where the file is going to be on a default
installation.

Otherwise I'm stuck with the standard PHP prefs file "confing.inc.php"
(- which is safe from prying eyes):
<?
if (defined("correct_entry_point")) {
my_pref[1] = "lots of good stuff";
}
?>

But updating this on pref changes is no fun compared to SQLite....

Please somebody tell me I'm wrong,
Cheers,
Adam

Zeev Suraski

22 years ago

At 13:56 23/08/2004, Adam Q wrote:

>Dear all,
>I feel I may have uncovered a potentially large difficulty for the
>adoption of SQLite.
>
>I think encryption for SQLite is essential for PHP. Without it, it makes
>it almost useless in a webscripting language.

Why is that?  You would have to gain file-level access on the server in
order to read any data.  With properly set permissions and reasonable
security, that shouldn't be possible.
I think that most database setups in general don't keep their information
encrypted, and the reasons they use username/password pairs is mainly
because (a) they're designed to serve multiple users (at the OS level) on
the same machine, and (b) they're designed to be accessed over the network.

Do you have some specific concern in mind?

Zeev

Adam Q

22 years ago

On 23/08/2004, at 7:24 PM, Zeev Suraski wrote:

> At 13:56 23/08/2004, Adam Q wrote:
>> Dear all,
>> I feel I may have uncovered a potentially large difficulty for the
>> adoption of SQLite.
>>
>> I think encryption for SQLite is essential for PHP. Without it, it
>> makes it almost useless in a webscripting language.
>
> Why is that?  You would have to gain file-level access on the server
> in order to read any data.  With properly set permissions and
> reasonable security, that shouldn't be possible.

With my own tests there is no way to distinguish between the PHP SQLite
process trying to read data from the database (allowed) and Apache
trying to download the DB via - http://www.example.com/db/SQLITE.DB
(not allowed)
And I'm thinking specifically of shared hosting situations (where PHP
is used a great deal) where you are unable to change the hosting
configuration.
As I stated in my initial post... Yes it is possible to specifically
deny access to the file for Apache/IIS... but for an open source PHP
project this creates too many complications to make it feasible. IIS
does not recognise ".htaccess" files so including something like that
with the project is only part of the way there....

As an example:
Many users of phpMyAdmin drop it in in their shared hosting providers
"/home/my_new_website/www" directory (ie it is directly accessible via
http). I know that many "grand-poobahs" of Internet security would say
this is a bad idea - but I know for a fact many people do it... because
it is easy.
For an open source PHP project to include a SQLite DB of any kind, for
install by "the masses", would be very open to misuse... It's just too
easy to download the _entire_ SQLite database - no SQL injection
attacks needed.
I for one would never do it.

> I think that most database setups in general don't keep their
> information encrypted, and the reasons they use username/password
> pairs is mainly because (a) they're designed to serve multiple users
> (at the OS level) on the same machine, and (b) they're designed to be
> accessed over the network.

The data in the database may not be encrypted, but I pay good money for
the relative security that nobody else can read the data in my database
(even in a shared hosting situation) provided by the fact that only I
know the password to the database....
With an SQLite database I have only security by "obscurity" I.e. hide
the file or make it an unusual name nobody would guess. (with an open
source project this is pretty difficult unless you generate a random
name on first install)

Would having a password for SQLite access be a bad idea? (In a web
scripting application I think not)

And finally, could someone please provide a web scripting use of SQLite
where it was a good choice?

Thanks,
Adam

Zeev Suraski

22 years ago

At 15:18 23/08/2004, Adam Q wrote:

>On 23/08/2004, at 7:24 PM, Zeev Suraski wrote:
>
>>At 13:56 23/08/2004, Adam Q wrote:
>>>Dear all,
>>>I feel I may have uncovered a potentially large difficulty for the
>>>adoption of SQLite.
>>>
>>>I think encryption for SQLite is essential for PHP. Without it, it makes
>>>it almost useless in a webscripting language.
>>
>>Why is that?  You would have to gain file-level access on the server in
>>order to read any data.  With properly set permissions and reasonable
>>security, that shouldn't be possible.
>
>With my own tests there is no way to distinguish between the PHP SQLite
>process trying to read data from the database (allowed) and Apache trying
>to download the DB via - http://www.example.com/db/SQLITE.DB (not allowed)

Hrm, well, it's a very bad idea to put the database anywhere under the
document root, because then you'd obviously be serving it for everyone to
download.  Encryption or no encryption, that's a very bad idea.
Instead, you should place the database file outside of the document root
(e.g. /usr/local/sqlite).  Make sure that this directory is properly
writable by the web server process and PHP, and you're done.

>And I'm thinking specifically of shared hosting situations (where PHP is
>used a great deal) where you are unable to change the hosting configuration.

These setups typically run with setuid and/or chroot solutions, which allow
you (or the hosting provider) to solve that issue.

>As I stated in my initial post... Yes it is possible to specifically deny
>access to the file for Apache/IIS... but for an open source PHP project
>this creates too many complications to make it feasible. IIS does not
>recognise ".htaccess" files so including something like that with the
>project is only part of the way there....

There's really no need to use anything special, as you can avoid the
problem altogether instead of trying to solve it.  You are right, though,
that if your particular hosting provider forces you to store the database
alongside the PHP files, it's not a good idea at all.

>The data in the database may not be encrypted, but I pay good money for
>the relative security that nobody else can read the data in my database
>(even in a shared hosting situation) provided by the fact that only I know
>the password to the database....
>With an SQLite database I have only security by "obscurity" I.e. hide the
>file or make it an unusual name nobody would guess. (with an open source
>project this is pretty difficult unless you generate a random name on
>first install)

I disagree about the differences in security models.  In certain ways
database servers are more vulnerable since they are designed to work with
remote users, which always opens the door for remote exploits.  SQLite, on
the other hand, relies completely on the operating system (and the system
administrator) to set it up properly, and once that's done - it's rock
solid secure.

>Would having a password for SQLite access be a bad idea? (In a web
>scripting application I think not)

Not sure, but it's certainly not the right solution to the problem you
mentioned.  A good combination of setuid, chroot and proper definition of
the per-user document root is the right solution for this problem.

Zeev

Adam Q

22 years ago

On 23/08/2004, at 8:27 PM, Zeev Suraski wrote:

> At 15:18 23/08/2004, Adam Q wrote:
>
>> On 23/08/2004, at 7:24 PM, Zeev Suraski wrote:
>>
>>> At 13:56 23/08/2004, Adam Q wrote:
>>>> Dear all,
>>>> I feel I may have uncovered a potentially large difficulty for the
>>>> adoption of SQLite.
>>>>
>>>> I think encryption for SQLite is essential for PHP. Without it, it
>>>> makes it almost useless in a webscripting language.
>>>
>>> Why is that?  You would have to gain file-level access on the server
>>> in order to read any data.  With properly set permissions and
>>> reasonable security, that shouldn't be possible.
>>
>> With my own tests there is no way to distinguish between the PHP
>> SQLite process trying to read data from the database (allowed) and
>> Apache trying to download the DB via -
>> http://www.example.com/db/SQLITE.DB (not allowed)
>
> Hrm, well, it's a very bad idea to put the database anywhere under the
> document root, because then you'd obviously be serving it for everyone
> to download.  Encryption or no encryption, that's a very bad idea.
> Instead, you should place the database file outside of the document
> root (e.g. /usr/local/sqlite).  Make sure that this directory is
> properly writable by the web server process and PHP, and you're done.

Putting the files outside the document root is secure, I agree... But
how can you be sure of this with an open source application (as opposed
to internally developed)? People are likely to drop your application
anywhere in their web tree they think it fits.

>> And I'm thinking specifically of shared hosting situations (where PHP
>> is used a great deal) where you are unable to change the hosting
>> configuration.
>
> These setups typically run with setuid and/or chroot solutions, which
> allow you (or the hosting provider) to solve that issue.

How can I ask people to contact their hosting provider for a special
setup before using my application?

>
> There's really no need to use anything special, as you can avoid the
> problem altogether instead of trying to solve it.  You are right,
> though, that if your particular hosting provider forces you to store
> the database alongside the PHP files, it's not a good idea at all.
>

Not force... Just a likely possibility

> I disagree about the differences in security models.  In certain ways
> database servers are more vulnerable since they are designed to work
> with remote users, which always opens the door for remote exploits.
> SQLite, on the other hand, relies completely on the operating system
> (and the system administrator) to set it up properly, and once that's
> done - it's rock solid secure.

OK. So I start to see where we are getting our wired crossed.
I am aware of the "best" ways to secure a PHP application. And I agree
with you if you put the DB outside the document root and follow
security best practices it can be seen as potentially more secure than
an SQL server.
But there is also the matter of making to easy for people to d/l and
use my application.... Which is my main point.
I would like to distribute a tarball for a PHP application that can be
dropped into someones website along the same lines as PostNuke,
phpMyAdmin etc (you get the idea). I would like to use a SQLite DB to
store the data for this application (so that the user doesn't need a
server setup as well), and I wanted to keep it all bundled together for
the sake of ease of install.
...Due to the complication of securing this setup SQLite can't be used
(IMHO)

And I also agree encrypting the DB is not a really fantastic
solution.... but provides a good deal of protection compared to
nothing.

Thanks,
Adam

Derick Rethans

22 years ago

On Mon, 23 Aug 2004, Adam Q wrote:

> > Hrm, well, it's a very bad idea to put the database anywhere under the
> > document root, because then you'd obviously be serving it for everyone
> > to download.  Encryption or no encryption, that's a very bad idea.
> > Instead, you should place the database file outside of the document
> > root (e.g. /usr/local/sqlite).  Make sure that this directory is
> > properly writable by the web server process and PHP, and you're done.
>
> Putting the files outside the document root is secure, I agree... But
> how can you be sure of this with an open source application (as opposed
> to internally developed)? People are likely to drop your application
> anywhere in their web tree they think it fits.
>
> >> And I'm thinking specifically of shared hosting situations (where PHP
> >> is used a great deal) where you are unable to change the hosting
> >> configuration.
> >
> > These setups typically run with setuid and/or chroot solutions, which
> > allow you (or the hosting provider) to solve that issue.
>
> How can I ask people to contact their hosting provider for a special
> setup before using my application?

All shared hosts that I saw already provide you with such space. THey
give you /home/your_site_name and in there www/ which is the webroot.
YOu can do whatever you want in /home/your_site_name

> I would like to distribute a tarball for a PHP application that can be
> dropped into someones website along the same lines as PostNuke,
> phpMyAdmin etc (you get the idea).

Perhaps this is exactly why PostNuke is considered insecure?

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Kevin Waterson

22 years ago

This one time, at band camp, Derick Rethans <derick@php.net> wrote:

> > I would like to distribute a tarball for a PHP application that can be
> > dropped into someones website along the same lines as PostNuke,
> > phpMyAdmin etc (you get the idea).
>
> Perhaps this is exactly why PostNuke is considered insecure?

A simple solution is to hard code the path to the database as
$dbname = $_SERVER['DOCUMENT_ROOT'].'/../my_safe_db.sqlite

The database will be created outside the web root and in
user space.

Kevin

--
______
(_____ \
_____) )  ____   ____   ____   ____
|  ____/  / _  ) / _  | / ___) / _  )
| |      ( (/ / ( ( | |( (___ ( (/ /
|_|       \____) \_||_| \____) \____)
Kevin Waterson
Port Macquarie, Australia

Lukas Smith

22 years ago

Adam Q wrote:

> Putting the files outside the document root is secure, I agree... But
> how can you be sure of this with an open source application (as opposed
> to internally developed)? People are likely to drop your application
> anywhere in their web tree they think it fits.

you document the problem ..
you can even try to implement some detection based on the relativ
location from the database file and the script that was called.

but in the end if incompetent people setup a system it is bound to have
flaws. if they are not willing to pay competent people its their problem
really, especially if they are also too lazy to read the docs and take
care of warnings. this will be the same problem regardless if its
opensource or not.

regards,
Lukas

Friedhelm Betz

22 years ago

On Monday 23 August 2004 14:27, Zeev Suraski wrote:

[...]

>
> Hrm, well, it's a very bad idea to put the database anywhere under the
> document root, because then you'd obviously be serving it for everyone to
> download.  Encryption or no encryption, that's a very bad idea.
> Instead, you should place the database file outside of the document root
> (e.g. /usr/local/sqlite).  Make sure that this directory is properly
> writable by the web server process and PHP, and you're done.

Running mod_php under safe_mode in an shared hosting environment this is
hardly to manage;-)

Regards
Friedhelm

--
www.hostsahring.net/

Gareth Ardron

22 years ago

On Mon, 2004-08-23 at 12:24, Zeev Suraski wrote:

> I think that most database setups in general don't keep their information
> encrypted, and the reasons they use username/password pairs is mainly
> because (a) they're designed to serve multiple users (at the OS level) on
> the same machine, and (b) they're designed to be accessed over the network.

Indeed - if I were to copy a bunch of mysql data files out from
$random_server and pop them in my own mysql server, I'd still be able to
read the data.

Unnamed Person

22 years ago

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
and/or password that would be used to access the database.  If the database is
encrypted, there must be authentication information available to the script
that's going to access the database.  That's just as insecure.

If you really want an SQLite dataabase to be encrypted, the author of SQLite,
D. Richard Hipp, has a non-free (one-time royalty, I believe) enhancement to
add that feature.  You can find his email address at the sqlite site,
http://www.sqlite.org

Derrell

Adam Q

22 years ago

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

Ilia A.

22 years ago

Here is the simple truth, if you are using a shared hosting solution that is
not VPS (Virtual Private Server) it would be relatively trivial for other
users of the system to access any file that the webserver has access to. Now,
because webserver will need access privileges to various PHP configuration
file that means that those users can read then and consequently grab your
passwords.

The only exception to this rule being if PHP is used as CGI or a separate
Apache process is running for each user. In this case given proper file
permissions (Ex. 0600) it would be nearly impossible for other users of the
system to read yourfiles without 1st gaining root access on the machine.

An Sqlite database is nothing more then a binary file, and you should treat it
such. If you do not want to have people being able to download it, do not put
it inside a web accessible directory.

Another trick you can do is to give your sqlite database a .php extension and
create a table that would cause PHP to generate a parse error when trying to
send the database to the user.
Ex. create table '<?php' (a);

This will make it impossible for people to download the data inside your
database.

Ilia

Shaun Thomas

22 years ago

Ilia Alshanetsky wrote:

> An Sqlite database is nothing more then a binary file, and you should treat it
> such. If you do not want to have people being able to download it, do not put
> it inside a web accessible directory.

Or, don't forget the existance of .htaccess files.  Want to block sqlite
files by default with an application you distribute, and you don't know
where the user will drop the files?  Put one of these in the root of
your application in a .htaccess file:

<files *.sqlite>
order deny,allow
deny from all
</files>

Either way, I don't see how this is a PHP or sqlite issue of any kind.
Server security through file restriction is a problem with many
solutions that are beyond the scope of this mailing list, IMO.

--
Shaun M. Thomas                INN Database Administrator
Phone: (309) 743-0812          Fax  : (309) 743-0830
Email: sthomas@townnews.com    Web  : www.townnews.com

Sterling Hughes

22 years ago

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:

Zeev Suraski

22 years ago

At 17:16 23/08/2004, Ilia Alshanetsky wrote:

>Here is the simple truth, if you are using a shared hosting solution that is
>not VPS (Virtual Private Server) it would be relatively trivial for other
>users of the system to access any file that the webserver has access to.

The point is that hosting companies, especially those using chroot, have to
make sure that they don't force their users to store the database files in
web-accessible locations, since the server is most probably designed to be
able to serve files owned by the user, and these database files fall under
that category.
Your <? trick is a cool idea though :)

Zeev

Ilia A.

22 years ago

On August 23, 2004 12:34 pm, Zeev Suraski wrote:

> The point is that hosting companies, especially those using chroot, have to
> make sure that they don't force their users to store the database files in
> web-accessible locations, since the server is most probably designed to be
> able to serve files owned by the user, and these database files fall under
> that category.

They also need to make sure that open_basedir (if used) will allow reading of
files from directories below the doc root.

Ilia

Adam Q

22 years ago

On 24/08/2004, at 12:34 AM, Zeev Suraski wrote:

> At 17:16 23/08/2004, Ilia Alshanetsky wrote:
>> Here is the simple truth, if you are using a shared hosting solution
>> that is
>> not VPS (Virtual Private Server) it would be relatively trivial for
>> other
>> users of the system to access any file that the webserver has access
>> to.
>
> Your <? trick is a cool idea though :)
>
> Zeev
>

Yes, I think that <? idea is what I was hoping somebody would
provide!!! ;) I could have the answer I was looking for (but didn't
know how to find ;)
I hope nobody though I was overly zealous in my stating my point. ;(
But I didn't want to be brushed aside, just because I was saying
something as yet unsolved.

I thought more about the issue last night and I guess it can be
summaried as thus:
In skilled hands an SQLite DB can be potentially more secure than a
standard DB - but in unskilled hands the reverse is true, and SQLite
becomes seriously insecure. Standard DBs don't vary to the same extent.

Could we have SQLite DB creation "option" that creates the DB with a
header that begins <?php? (SQLite DBs are close to normal text in the
first 20 chars anyway... ) - either way, I'm going to do some testing
of Ilia's create table option and see if I can get around it.

Wow I can't believe I might be able to use an SQLite DB after all.

Thanks all,
Adam

Ilia A.

22 years ago

On August 24, 2004 09:10 am, Adam Q wrote:

> Could we have SQLite DB creation "option" that creates the DB with a
> header that begins <?php? (SQLite DBs are close to normal text in the
> first 20 chars anyway... ) - either way, I'm going to do some testing
> of Ilia's create table option and see if I can get around it.

No, the reason is that my "solution" is a hack, arguably a very dirty hack
that relies on the fact that the table structure in sqlite in stored as plain
text rather then as binary data like the rest of the information inside the
database file. This means that if this storage mechanism were to change this
hack would stop working.

If you need to use this hack just make a wrapper function around sqlite_open
that would create this table if it does not already exist, (you can check
sqlite_master table for it's presense).

As far as making PHP do this automatically, I am definitely against this for
the reasons mentioned above.

Ilia

Rasmus Lerdorf

22 years ago

On Tue, 24 Aug 2004, Adam Q wrote:

> I thought more about the issue last night and I guess it can be summaried as
> thus:
> In skilled hands an SQLite DB can be potentially more secure than a standard
> DB - but in unskilled hands the reverse is true, and SQLite becomes seriously
> insecure. Standard DBs don't vary to the same extent.
>
> Could we have SQLite DB creation "option" that creates the DB with a header
> that begins <?php? (SQLite DBs are close to normal text in the first 20 chars
> anyway... ) - either way, I'm going to do some testing of Ilia's create table
> option and see if I can get around it.
>
> Wow I can't believe I might be able to use an SQLite DB after all.

I still don't understand this entire thread.  If you insist on making the
file accessible from your DocRoot why can't you simply block any direct
access to it via an Apache rule?

Something like:

<Files ~ "\.sql$">
Order allow,deny
Deny from all
</Files>

And then name your sqlite files whatever.sql

And no, we are not going to mangle every sqlite DB we create by sticking
<?php in it and suggesting that people feed their sqlite DB files through
the PHP parser.  What if someone comes along and comes up with a hack that
changes the first table name to <?system("rm *") ?  I would hate to have
to explain to people that we promoted that sort of idiotic hack.

-Rasmus

Wez Furlong

22 years ago

I don't get this thread either...
it's no more or less secure than anything else you store in a file.
We are not going to hack libsqlite or change anything else in PHP to
cater for this--it really isn't our problem.

If you have a cheap provider that insists on putting your private data
under the web root, it's time to use someone else or shell out more
cash: either upgrade to a better host or pay for the crypto-enabled
sqlite library (contact the sqlite author for more information).

--Wez.

On Tue, 24 Aug 2004 09:22:39 -0700 (Pacific Standard Time), Rasmus
Lerdorf <rasmus@php.net> wrote:

Wez Furlong

22 years ago

it's worth noting that the crypto-enabled version probably won't work
with PHP without some (simple) patching.

In case it isn't clear, the message is: don't put the files under the
web root.  If you provider forces you to do that and offers no other
way to control security, find one that does.

--Wez.

On Tue, 24 Aug 2004 18:26:37 +0100, Wez Furlong <kingwez@gmail.com> wrote:

Zeev Suraski

22 years ago

At 19:34 23/08/2004, Sterling Hughes wrote:

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

If it is we should be worried - time to check our disclaimers :)

Zeev

Chris Shiflett

22 years ago

--- Adam Q <aqsalter@westnet.com.au> wrote:

> The database needs a password.... otherwise it is just too much of a
> security risk.

Based on my observation of the conversation you've been having, I think
you might be making things too complex on yourself. This database is just
a file. So, think of having a file named database.txt, and then think
about how you would secure the data therein.

Hope that helps.

Chris

George Schlossnagle

22 years ago

On Aug 23, 2004, at 4:04 PM, Chris Shiflett wrote:

> --- Adam Q <aqsalter@westnet.com.au> wrote:
>> The database needs a password.... otherwise it is just too much of a
>> security risk.
>
> Based on my observation of the conversation you've been having, I think
> you might be making things too complex on yourself. This database is
> just
> a file. So, think of having a file named database.txt, and then think
> about how you would secure the data therein.

To beat the point into the ground, if you put your mysql datafiles in
your docroot, anyone can compromise those too, irregardless of your
database password.

George