|
Stamp_Guy has asked for the wisdom of the Perl Monks concerning the following question:
Here's a problem I'm facing: I have a Perl script that modifies files for a person to update their site. I only want that person to be able to update it and I need to know if the password setup I'm thinking of would work. I'm thinking of just password protecting the directory. Is this secure enough? I have no access to an SSL connection or anything that elaborate, but I'd be open to suggestions of good password protection schemes for something like this. |
Re: Perl/CGI Security Question
by chromatic (Archbishop) on Mar 29, 2001 at 11:00 UTC
|
If you mean using something like Apache's .htaccess, that's a decent level of security. Be aware that relying on HTTP Authentication isn't as secure as an encrypted connection -- the username and password are sent out in HTTP Headers in plain text.
Anyone dedicated with sufficient time could sniff the appropriate packets. It's better than nothing, though, and it's not hard to use. (Hey, PerlMonks uses cookies to verify identity, which have the same problem. Not that vroom is storing compromising photos of EDC employees on kali or anything...) | [reply] |
Re: Perl/CGI Security Question
by Xxaxx (Monk) on Mar 29, 2001 at 16:22 UTC
|
Not sure what you're planning.
If you are thinking of .htaccess on a directory
containing the forms, then using HTTP_REFERER as a
check at the script level then you are open to one serious
problem: HTTP_REFERER spoofing.
Your scripts will still be accessible by someone spoofing their
environmental variables. It's not that hard to do. It's like
hot wiring a car. Maybe not everyone knows how, but enough do
that it's a problem.
So to make the scripts a little more secure: .htaccess with
password verification at the form level might be a
good idea.
Then to keep the poor user from having to input the password
each time combine with cookies. It's a kind of double login which
might be worth the effort.
Hope this helps,
Claude
| [reply] |
Re: Perl/CGI Security Question
by rbi (Monk) on Mar 29, 2001 at 13:39 UTC
|
I'd suggest you the documentation of user_manage, a script by Lincoln Stein.
There you can find a lot of answers and ideas (...and at the end you''ll probably use the script itself or something very similar :) ).
Hope this helps
ciao, Roberto | [reply] |
Re: Perl/CGI Security Question
by coolmichael (Deacon) on Mar 29, 2001 at 12:17 UTC
|
I've helped people out with .htaccess style password security, and had good results with it. It was kind of fun, we were both fumbling our way through it, but that's off the topic. Since then the other person has gone on to publish large amounts of data that way. As chromatic writes, it's not the most secure way, but sending the username and password base64 encoded is better than sending them in plain text. At least in my (limited) experience.
YMMV
Michael,
the blue haired monk. | [reply] |
Re: Perl/CGI Security Question
by perlcgi (Hermit) on Mar 29, 2001 at 18:23 UTC
|
If you have Apache on the server-side, check out if mod_auth_digest has been included. Digest authentication provides a more secure password system than Basic authentication, but only works with IE5 and probably Netscape 6. Also there's a nice chapter on Access Control, Authentication, and Authorization in Writing Apache Modules with Perl and C. Good luck! | [reply] |
Re: Perl/CGI Security Question
by cLive ;-) (Prior) on Mar 30, 2001 at 10:22 UTC
|
Another issue if the data is on a shared server might be "Who is the script running as?"
If nobody, then your data will need permissions of 777 -> anyone can read or update your data files through a simple perl script if they know they are there.
If this is an issue, you (or your sys admin :) should install cgiwrap. Then you can run your script as owner, and set permissions on data to 700.
cLive ;-)
PS - I've written a grey hat cgi-script that acts as a simple 'explorer' for the machine you're on. On install, you can browse directories/files that are world readable on the server you're on. It wouldn't take much to turn it into an editor for all files that are world writable as well :)
Basically, if you're not the only user on the server, assume the data will be read if permissions are 777. If this is a problem, get cgiwrap up and running :) | [reply] |
|
|
Erm... unless the data needs to be executable for some reason, plain files can (and probably should be) at most mode 666. Mode 777 (world readable, writable, executable) would not only let anyone modify the data, but may let anyone execute any program as the webserver user, depending on how the server's configured. It's very rare that a file will need to be mode 777, IME.
Realistically, you could probably get away with mode 644 if you chowned the file to the user the webserver runs as.
| [reply] |
|
|
sorry,
I have a weird superstition about using 666 permissions (call me silly, please). No, I'm not a christian, just think it's too much of a coincidence that 666 == pure evil in terms of file permissions :) and the extra 1 doesn't really matter that much... (or does it? thoughts...)
But yes, you are right. Immaterial really, coz you should be running stuff at 700/600/400 with cgiwrap anyway (or equivalent :)
later
cLive ;-)
>Realistically, you could probably get away with mode 644 if you chowned the file to the user the webserver runs as.
644/666 - does it really make a difference if the script's not wrapped? Either way the file's open to abuse by other users on the server...
| [reply] |
|
|
|
|
Re: Perl/CGI Security Question
by dws (Chancellor) on Mar 31, 2001 at 06:41 UTC
|
If you're not able to get SSL/SSH connections working, you can attach a password to an upload form (upload scripts have been discussed to death here. Consult Super Search). This means sending a password in cleartext, but you can mitigate that risk by using a one-time pad.
It works like this: Establish a list of words (randomly, one supposes), and give a copy of the list to the person who'll be updating the website. The upload CGI script gets the other copy. Each time a file gets uploaded, the upload script checks the first word on the list, deleting the word if it matches (or rejecting the upload if it doesn't match).
The sender scratches the word of their copy of the list. If some l337 h4x0r sniffs packets and grabs the password, no damage is done: that password is now stale.
Alternatively, the upload script can try to match/remove a word from anywhere in the list. This allows you to split the list into pieces that you can give to different people.
The downside of this scheme is that it you'll need to periodically generate and distribute new lists.
| [reply] |
|
|
