At 9:04 PM -0500 11/23/03, Vania Smrkovski wrote: > Speaking to the first question, regarding security of data, aside from >some of the obvious, like putting the DB files out of the web document >tree, are there any ways to configure SQLite to keep the DB files in >some non-readable format? I had hoped to use an architecture where each >web application had a SQLite DB in the same folder for session and >storage of data useful only to that app, and to have a general SQLite DB >file elsewhere for all apps to use, but was somewhat startled when I >tried accessing the SQLite file directly in my browser and got almost >perfectly readable data dumped to my screen.... I was hoping that I >might have overlooked a configuration switch that would make the file >unreadable, but have not found this yet....
What you describe is a general website design flaw and/or gaping security hole on your part and has nothing specifically to do with SQLite. The fact is that any individual files on your web server which are not supposed to be directly invoked or downloaded by a client web browser (or robot) should not be inside any public directory. You should store all of these files, including any SQLite databases for sessions, somewhere else on your server. No one can download your database if there is no web address that corresponds to it, can they? For my part, I set up my web applications (all written in Perl 5 currently) like this (simplified for illustration): /users/me /users/me/private_files /users/me/private_files/mylib1.pm /users/me/private_files/mylib2.pm /users/me/private_files/mydata1.txt /users/me/private_files/mydata2.db /users/me/private_files/mymain.pl /users/me/public_files /users/me/public_files/default.pl -> soft link -> ../private_files/mymain.pl /users/me/public_files/myimage1.gif /users/me/public_files/myimage2.gif So only items in public_files can be invoked or downloaded. No one can see the items in private_files, which includes the source code of my Perl library files, which don't execute. The main program, mymain, is very minimalist and doesn't contain any sensitive data; it mainly just calls a function in one of my libraries that does the real work; this also means if the web server has a bad day and becomes misconfigured, making the perl script a source-downloadable file, no one is seeing anything important. The catch with the above approach is that you have to explicitely change the current working directory or use path references to files. You can't simply say "open this file in my current directory", since the "current" directory is the public folder. -- Darren Duncan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
