Gossamer Forum
Home : Products : DBMan : Customization :

$per_admin isn't that "safe"

Quote Reply
$per_admin isn't that "safe"
I have everything set up nicely... If they're admin, they can see the address that someone adds to their record. If they're not, they can't. This is for reasons of privacy.

However, I just realized that if you type the right url to the database file they can see it right there and then, including the address. I could put some really random file name which no one would guess, but I'm wondering if there is a better way with chmod or anything else to fix it. I tried chmod 660 default.db, but the database can't open it. Any ideas?

Nelson
Quote Reply
Re: $per_admin isn't that "safe" In reply to
Nelson:

How do you have this field setup in your html_record or html_record_long?

Is it something like this:

|;
if ($per_admin) { print qq| $rec{'Address'}|; }
print qq|

This should not display the address unless the user has admin permissions.

Hope this helps Smile

Quote Reply
Re: $per_admin isn't that "safe" In reply to
I was just reading the readme.txt file, and it does say this: The only file that should be accessible from the net is db.cgi.
All requests to the script will go through db.cgi, and letting people
view the password file or auth directory is a major security risk
(risk to DBMan's built in security, not to the security of the system).


I do have the same chmods as the file too..

Nelson
P.S. I was just thinking...could it be that I can see the file because I'm connecting from the same domain?
Quote Reply
Re: $per_admin isn't that "safe" In reply to
Everything works fine when I run the script. What I'm saying is that if I type the right URL (e.g. www.somewhere.com/cgi-bin/default.db or default.pl or default.pass) I can see the bare file.

Nelson
Quote Reply
Re: $per_admin isn't that "safe" In reply to
That's a server issue. Different servers have different setups.

On my server, if something is in the cgi-bin, it can't be directly accessed. You can check it out by trying to see http://www.jpdeni.com/...bin/books/default.db . This is also why you can't put graphics within the cgi-bin on many systems and why I always tell people to copy their files that they want me to see into a "web-accessible directory."

I don't know what the difference is -- whether its a Unix vs Windows thing or what. But I'm pretty sure your server could be made more secure than it is.


------------------
JPD






Quote Reply
Re: $per_admin isn't that "safe" In reply to
This generally happens for 1 of 2 reasons.
#1. Your on an NT server.
#2. You installed the script outside a a cgi-bin.

A properly configured web server will not allow you to download or browse any files under a cgi-bin.

In my experience, 60% of the NT web servers out there are configured improperly and allow you to download or browse files, just because you know where they are. Not good! I find that many companies find an NT server sitting in the corner, throw IIS on it, and call it a web server.

An improper, but quick fix is to get in touch with the system administrator, and ask him to remove some permissions from the critical files. I believe you can ask to have the Read permissions removed. The script will still function properly, and they won't be able to download files like default.pass or default.db, etc.

However, I have seen some professional NT web hosts, that have their act together, and you can install any script under their cgi-bin and it's secure, without needing to ask them to fine tune specific file permissions. It's almost as if they set a certain permission on their cgi-bin and it acts recursively for all sub directories.

To this day, nobody has been able to tell me the correct settings for how to set up an NT cgi-bin properly. Yes, people have told me how to do the quick fixes to the individual files, but nobody seems to know how to set the proper changes one time (probably somewhere in the IIS or NTFS permissions.) If anyone knows, please post it here so we can get our NT system admins all straightened out.
Quote Reply
Re: $per_admin isn't that "safe" In reply to
I believe the quickest fix would be to put an index.html file in the cgi directory in question. This will keep people from browsing the files, unless they happen to know the file name (easy to change your names from the default).

Dan
Quote Reply
Re: $per_admin isn't that "safe" In reply to
No, we are not referring to browsing a directory of files. We are referring to typing in a file location and having it appear as text output, or it starts to download.
Quote Reply
Re: $per_admin isn't that "safe" In reply to
Well, I had put an index.html file sometime back, so they can't see all the files. And no, it's not a Windows NT server. It's either on a Unix or SunOS server. I'm not sure which of the two it is on because I can telnet to either and go to the same web directory. These 2 servers are from a university I go to (www.andrews.edu).

Nelson
Quote Reply
Re: $per_admin isn't that "safe" In reply to
Right, but if you don't use the default file names, people will have no way of guessing your naming convention and the index file will keep them from browsing the directory. The net effect is that the directory is (thinly) protected.

Dan
Quote Reply
Re: $per_admin isn't that "safe" In reply to
Nelson et al,

Two suggestions:

1) Put all your files except db.cgi in a password protected directory.

2) To disallow directory browsing across all your directories (for UNIX servers only), edit your .htaccess file to include the following codes:

Code:
DirectoryIndex index.cgi index.shtml index.html index.htm /errors/forbidden.shtm
l

For NT, of course, you can turn off directory browsing via the IIS Manager (If you are using IIS) or O'Reilly WebSite Manager (if you are using WebSite) or in the Apache Manager Console (if you are using the Apache for 32 bit).

Regards,

------------------
Eliot Lee....
Former Handle: Eliot
Anthro TECH, L.L.C
anthrotech.com
* Check Resource Center
* Search Forums
* Thinking out of the box (codes) is not only fun, but effective.


Quote Reply
Re: $per_admin isn't that "safe" In reply to
Thanks for your help. I have just e-mailed the system admin. and hopefully he will fix it.

Nelson