Roderick wrote:
> Has anyone used text files via perl or php as
> "database" storage, SECURELY??

I had a Perl CGI application that maintained
password files, using just the ordinary
CGI authentication scheme (htaccess).
Those password files were encrypted, of course.

But the web server, and the CGIs under it,
ran under the user ID of the application it
was serving.  All the files and directories
this system used were accessible only to that
one user ID.  Thus no valid telnet-connected
user of the system could poke around in the
application's files.  Only the system
administrators had the password to this
user ID.  I was unable to crack my own app.
Of course maybe I wasn't twisted enough.  ;-)

Remember that any CGI that is activated by
the web server runs under the user ID that
the server runs under, and can do anything
that user can do.  So code very carefully.
Specifically, be very careful of all
file operations with variable file names,
or system or "exec" or "eval" calls, since
those are what can do the most harm if
they are working with malicious data.

Remember your CGI might be called by a
malicious form that does not follow the
expected rules.  Check for oversized input.

If CGI execution is limited to a specific
set of directories, don't let any extraneous
files get left in those directories.

Another approach is to run the server under
the "nobody" ID which is a member of the
"nobody" group, so the CGIs can do no harm.
But if this makes you give all sorts of
files 755 permissions, you have negated the
benefit.  So design your whole permissions
structure very carefully.

Note that you need some sort of locking scheme
for any file maintained via CGIs, since more
than one instance might be in play at a given
moment.  The "flock" advisory lock command
works fine as long as any accessors play by
the rules.

Don't put any sensitive data under your
DOCUMENT_ROOT directory.  Put the password
files somewhere else, so there's no way that
the web server can allow the web user to
view them.

Read up on CGI security and exploits.

Distrust all your input, especially watching
for any field that might find its way into a
file name or system command.  Disallow any
characters that are not obviously needed in
a given field.  A password can contain
anything, but most fields for most
purposes should match \w and a carefully
selected set of punctuation marks.
Disallow field names that are not known
to the program.

There are some good summaries on the Web.
Can't cover it all here by any means.

Who mentioned the "exists" test for
hash entries?  Good policy.  And of
course "use strict".  Set -w while you
are debugging, and debug until you are not
getting any warning messages.  But don't
use -w when running a CGI in production:
you don't want to start returning invalid
web pages because of some silly warning.

Check everything.  Your Perl programs will
balloon in size, but REAL programs are like
that.  What you posted originally was a
faint shadow of all the IFs, ANDs and BUTs
that are needed in a production environment.

But you have to get it talking to you before
you start shooting for Perfection.

Have fun.

Vic