SQLite security

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

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:

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