Every now and then, I'm reminded off this little dilemma, as did a recent posting on the monastery: securing your scripts/passwords.

The use of databases in conjunction with Perl (or whatever language for this matter) to generate dynamic content websites increases, and usually you need an account (username/password) to connect to the database daemon.

As I explained in my reply to the before mentioned posting, the problem comes in when there are other users on a server (and a lot of us can't afford our own dedicated machine ... I think). Since Apache (or whatever http daemon) needs to be able to read the script and passwords, so can almost every other user on the system.

I once had an account on a webhosting company's machine and just used a few shell commands to grep through some files in the other users' "web directories". Shockingly (or not), I got close to all users' passwords to the databases, which -how bad- were identical to their shell accounts (please note: I had the company's OK on this little test). A few users with some clue disabled reading permissions in their "web directory" making the quest a little harder, but a less /path/to/specific/dir/index.cgi did wonders (you can read what files are included from there on).

How to prevent such horrible people (like myself) to snoop the passwords, or better yet, how to make the damage as little as possible? I've heard that RSBAC on Linux machines could possibly help, but how many people are going to persuade a company to implement this (and succeed)?

So far, I have thought of the following things that could shoo clueless scriptkiddies away:

• Read permissions of "webdir".
As mentioned above, turning these permissions off doesn't prevent other users from reading the files, but at least they can't grep through your files.
• Store passwords in a different file with "nobody" as only user to be able to read the file.
Again, this doesn't solve the problem, but users won't be able to snoop through the file from a command line and need to write a webinterface, possibly shying them away. In other words, security through obscurity (which usually doesn't work, as with this example ;).
• Using read-only database accounts only.
If the database is only used to feed the website, it's far from necessary to let that (database)user have write (or update) permissions. Have another user with write/update permissions and add files manually, not through a webinterface (or ask the password on the webinterface (SSL?)). This is probably not too hard to ask a sysadmin to do for you.

So far, I think the last option is the best (don't store passwords for updating accounts at all, but prompt for them), but I'm curious about other "solutions".

--
b10m

All code is usually tested, but rarely trusted.

In reply to Securing your scripts on webhoster's server by b10m

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.