[EMAIL PROTECTED] wrote:
> Hello!
>
> This is probably something trivial, in which case I apologize, however I'm quite new
> in Perl and even more so in databases. Actually, I'm quite new in programing at all,
> so please don't laugh at me.
>
> I'm basically concerned about the security of writing a simple web frontend to SQL
> database, the most important question being: how should I store the database
> password?
>
> Every example I have found so far about using DBI or Class:DBI or anything includes
> the password as a cleartext in the source code. I realise that it's just for the
> sake of code examples simplicity and anyone had to be insane to introduce such a
> serious vulnerability in a production system, but frankly I'm not quite sure how to
> do it right.
>
> Should I make my CGI scripts not directly readable/executable to the httpd processes
> and write a suid wrapper which would then run the script itself including the
> password in the source code or reading it from a filesystem?
>
> What about the database itself access privilages? Should I use different accounts
> for different scripts, depanding on what access do they need to have?
>
> The most obvious solution seems to be something like this: For example, there's a
> news website. Everyone can read news, but only admin can add/modify them. So there
> need to be two system user accounts, e.g. newsadmin and newsguest, with the same
> accounts in the database having respectively read/write and read only (of course I'm
> simplifying, it whould be select privilage, insert, etc.) and two CGI scripts with
> an appropriate suid wrapper each.
>
> The problem is that having many indepandant websites on the same server can cause a
> need to have quite a lot of OS and DB accounts, so I'm asking if this is indeed the
> way to go, or maybe I'm missing something?
>
> So I'd like to ask all of you experienced Perl developers: How do you solve the
> problem of database security in production environments yourself, especially when
> the website is not the only one on the system and not the only one using a given
> database?
>
> I'm sorry if I'm asking a stupid question maybe missing an obvious answer, but I'm
> just beginning my first Perl/database project and everything I have are some
> terrible examples left by someone working here before, who was obviously completely
> security-wise ignorant and now I have to clean all of this mess he left here.
>
> There are tens of websites on the server and every database access is done with an
> account having full (sic) access to all of the tables and - if that wasn't enough -
> the password is in the clear in the sourcecode which is all world readable! No
> wonder why the previous admin was fired.
>
> I'd be grateful if anyone could point me to some documentation which I failed to
> find or just say few simple tips. Thanks a lot!
>
> (Should I post it to [EMAIL PROTECTED] It's indeed a problem with CGI scripts, but
> the problem itself is not stricte CGI-related, so I'm not quite sure.)
>
> Thanks!
> -Zedgar Z.
Although only a slight improvement, it can help to shift the database out of the cgi
directory. On the server I use, the web server runs as part of the group. There fore
if a side directory has chmod 660, the server can access it, but the world can not.
Unfortunately others considered to be part of the same group can also read it. It
really depends then on the granularity of the pemissions system on the server.
The strucure would be like
Home
db_adm
public_html
cgi-bin
Filepaths from the script should then be based on ../../db_adm/. Keeping the paths
relative helps keep the code portable.
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
