Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number


by Anonymous Monk
on May 23, 2001 at 18:14 UTC ( [id://82560]=perlquestion: print w/replies, xml ) Need Help??

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I want to begin making front ends for all of my scripts. These administrative front ends may include multiple pages. What would be the best way to secure the whole administrative front end?

Should I put a cookie on the administrator's computer, to verify that he is actually the administrator.

I mean, I really have no idea what is the best security method for an administrative section that may have multiple scripts... but only request a password once, at the main page script.

Any links to security info would be appreachiated. Any extra tips would be apprechiated as well.


Edited 2001-05-23 by Ovid

Replies are listed 'Best First'.
Re: Security
by arhuman (Vicar) on May 23, 2001 at 18:16 UTC
    • perldoc perlsec
    • Super Search
    • The Camel Book
    • Security sites (securityfocus, phrack, checksum...)
      To name few sources, should give you enough details about

      • Taint checking
      • Right checking
      • Race conditions
      • Authentication/encryption
      • Data validation (buffer overflow, escape characters, NULL poison, format strings...)
      • Advices about unsecure protocol using plaintext password (ftp, pop3...)
      • ...

    "Only Bad Coders Code Badly In Perl" (OBC2BIP)
Re: Security
by Hero Zzyzzx (Curate) on May 23, 2001 at 18:28 UTC

    I think a good, relatively easy, security model to implement is this:

    • Store user and password info in a database. Be sure to encrypt the password. If you're using mySQL, the password() function can do this for you.
    • Have the user login. Check the password against the info in the database.
    • Assuming login success, set a md5 encrypted cookie and store the cookie in a "valid users" table server-side. Use some kind of random, hard-to-guess info in the md5 cookie, like localtime() plus a random number and some random text. One other thing is to not set an expiration time on the cookie, so that it expires when the user closes the browser session. This will require a login each time someone wants to access an admin feature.
    • Because you have the cookie stored in a database, you can use this to authenticate across multiple scripts. You should also clear the stored cookies out of the database every day or so.
    • The biggest hole here is probably sending password/user info plain text via the WWW. Use SSL for the login page.
    • You can also have admin functions built into the same scripts used by non-admin folks, by denying functions to folks without a valid cookie in your database. This is a big strength of this system, your security isn't an "all or nothing" proposition.
    • There's a bunch of assumptions I'm making here- that you're using strict, untainting data properly, and have read all the great links the other monks have provided in this thread. This is the "devil in the details."

    Make sure to take the time to learn for handling your cookies and other functions, you'll be glad you did.

    While this system isn't perfect, it should work for a moderately secure app. I wouldn't trust it with anything that handles credit cards or the like, but it should work well for anything below that.

(boo) Re: Security
by boo_radley (Parson) on May 23, 2001 at 18:21 UTC
    if these are cgi scripts that you're referring to, you may have a better go with your webserver's security rather than cobbling something together with perl.
    If you're using apache, I'd look at their security tips, as a start.

    Under no circumstances should a cookie be considered secure.

    Obperl : use strict; can only help ;)

Re: Security
by sierrathedog04 (Hermit) on May 23, 2001 at 20:08 UTC
    If you are using Apache server on Unix, then the type of security you seem to want is easy.

    Apache's built-in basic authentication can use the following three files:

    • .htaccess (for defining what groups are allowed to use a directory);
    • .htgroup (for defining who is in a group); and
    • .htpasswd (for storing the names and encrypted passwords of users.)

    For instance, let's say that you created a directory called SA and you only wanted users who are members of the SAgroup to have access. Then place in your SA directory an .htaccess file similar to the following:

    AuthName "Security Solutions Center HelpDesk" AuthType Basic AuthUserFile /mypath/.htpasswd AuthGroupFile /mypath/.htgroup <Limit GET POST> require group SAgroup </LIMIT> ~
    Your .htgroup file might look something like this:
    SAgroup: NM1121 Ella Mojo
    There are several ways to create your .htpasswd file of Apache users and their encrypted passwords. I like the htpasswd module on CPAN.

      Just for you to know :
      Be aware that Apache MD5 function used to store password,
      is not a standard one and is INCOMPATIBLE with Digest::MD5 or even other MD5 tools...

      "Only Bad Coders Code Badly In Perl" (OBC2BIP)

      Let Apache be your wheel!
Re: Security
by blue_cowdawg (Monsignor) on May 23, 2001 at 20:28 UTC

    Well my anonymous freind, there are many ways to skin this cat and probably using cookies is the least secure of these. After all I can always manufacture the cookie on my machine and masquerade as someone who has priveliges.

    The actual implementation is going to vary depending on what kind of web server you are using, the resources you have available to you, and political factors. For the sake of this discussion I will ignore the political factors.

    The simplest way of securing these and I believe the most universal would be to make use of .htaccess (?) files to secure the directories where the front end scripts live as well as any html pages. You would use the directive that requires a login/password and as long as the server in question can recognize the login/password tokens and validate them you are home free.

    Doing all this will probably require some reading on your part as milage varies with each server type.

    If you are using Apache and have mod_perl loaded and configured this opens up the way to some much more intelligent and flexible options.

    For one thing I would consider writing a mod_perl module that does authentication handling and arrange permission atributes for individual users to give them the access they need and no more. OBTW: this would also be a good way to set up some sort of audit trail to track who did what and when.

    As I said in my opening remarks there are many ways you can go with this.

    Peter L. Berghold --- Peter@Berghold.Net
    "Those who fail to learn from history are condemned to repeat it."

      I agree that cookies aren't the best way to do security. However. . .

      If you create your cookies using random data and with a one-way hash like MD5, and then store the cookies you create in a server-side database, then the cookie manufacturing becomes very difficult. You can send your manufactured cookies 'til the blue cows come home, but until one matches what's stored in the database, it's all for naught.

      Just my $.02. . .

      Update: Copying a cookie is different than manufacturing one. . .See below. . .

        If I copy a cookie from someone's browser (small amount of handwaving here on how I get it in the first place) then it doesn't really matter how I encode it unless I am using some sort of Diffie-Hellman pair. I'd still be stealing someone's identity.

        Unless there is some sort of challenge/response happening where the user has to perform some active function such as type in a password, use a smart card, or whatever using a client side cookie is just asking for trouble.

        Peter L. Berghold --- Peter@Berghold.Net
        "Those who fail to learn from history are condemned to repeat it."
Re: Security
by shotgunefx (Parson) on May 24, 2001 at 17:08 UTC
    I just like to add in addition to all the good posts above, if these scripts are interfacing to system utilities and or going to be run with any privilege, SANITY CHECK EVERYTHING!


    "To be civilized is to deny one's nature."

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://82560]
Approved by root
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (4)
As of 2024-06-20 16:06 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.