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

A search of the monestary turned up a plethora of CGI and session nodes, but the ones with interesting titles didn't seem to address this question directly. If I missed one, just point me in the right direction.

I need to add minimal security to an in-house app. It's all inside our firewall so I'm not concerned about outside malicious hacks. The main purpose is to prevent curious employees who stumble across the site from accidently entering data into the system. A secondary use might be storing session data if the system expands beyond its current humble state.

The approach I have in mind is to use a simple login screen to collect a user name and password. The CGI (Perl :)script would verify these against a database table and assign a session key (hash) with a short expiration time, e.g. 30 minutes or so. The session key would be kept in a hidden field on the subsequent forms.

Subsequent invocations of the CGI script would check for the hash in the user table and verify the time, and look up state information if/when it is implemented. Form submissions which lacked a session key, have expired, or have an invalid key would be returned to the login page.

Am I missing anything obvious here? Anything subtle? Fishing poles, bait, and even fish are welcome!

TiA, Mike

  • Comment on CGI Session 'security' for in-house app.

Replies are listed 'Best First'.
Re: CGI Session 'security' for in-house app.
by arashi (Priest) on Jul 06, 2001 at 00:29 UTC
    I asked a similar question a while back. There were many great responses, I found one of merlyn's columns (Web Techniques Column 61 - May 2001) in his The Web Techniques Perl Columns to be very helpful.

    I think you're on the right track. Here's what I think would be a good approach to the problem:
    • Users login to the system.
    • The system validates the user's name and password and assigns a session key into a cookie and a log file. (see merlyn's column)
    • Every time the user goes to a page, the CGI checks the cookie and compares it to the log file, if the user is valid, it will render the page. If the user doesn't validate, the form won't even render for them. This should stop any wandering users for "accidentally" finding a form and submitting data to it.
    Hope this helps.

    Arashi

    I'm sure Edison turned himself a lot of colors before he invented the lightbulb. - H.S.
[reply]
Re: CGI Session 'security' for in-house app.
by andreychek (Parson) on Jul 06, 2001 at 00:41 UTC
    I'm not sure exactly what type of answer you are looking for, but I'll see what I can do.

    First off -- no, it doesn't seem like you are missing anything. Secondly, there's no need to redo what's already been done. Unless you really believe you can do it better. In which case, highly consider adding onto the existing solution instead of re-implementing it. When it comes down to it, most people would agree to do these things when creating web applications:

  • Use CGI.pm for developing your applications
    No one will argue this. If you aren't using CGI.pm, you're asking for trouble.. both from you application, and us because we'll yell at you ;-)

  • Use Apache::Session for managing sessions
    Apache::Session will help create and manage you're sessions. It'll create unique session id's for you, you don't have to worry about that. In fact, I don't one should ever try and create session ID's on your own, there are too many ways to do it incorrectly and insecurely :-) However, as far as I know, there isn't yet a module to manage expiring of sessions, you'll most likely have to do that on your own. But thats easy enough if you store the last time a person was at the site in your database. Next time they connect, if the time is more then 30 minutes or whatever, just redirect them to the login page.

  • Encrypt Passwords using SSL and/or a Challenge Response System
    Even people within your building are capable of sniffing passwords. There are tools that do all the work for them. I would highly recommend doing something.. anything.. to make sure the passwords are not sent in clear text. Even internally.

    A point that I'll argue -- and there are definitely two (often religious) sides to this -- is that I feel one should always use some sort of templating system to create HTML templates when developing web applications. This seperates code from content. There are several available, HTML::Template and Template::Toolkit, to name 2. And then where CGI.pm comes in is to handle the input, sending out headers, and that sort of thing.

    Perhaps there are times to use CGI.pm for generating content. But I personally feel that using CGI.pm for this purpose would create messy applications, even if they do end up creating correct HTML ;-) But the point to argue there is that there are plenty of HTML validators you could use to validate your HTML code if you wanted to use a template. But in the end, it's your choice :-)
    -Eric
[reply]
Re: CGI Session 'security' for in-house app.
by Abigail (Deacon) on Jul 06, 2001 at 00:33 UTC
    A few points:
    • What does this have to do with Perl? It's the same problem if you implement it in C, Java or TECO macros.
    • Why hidden fields? HTTP already has authentication. Why not use that?
    • Why the short expiration time? Why any expiration time at all if all you want to prevent is curious employees entering data?

    -- Abigail

[reply]
      It's not really the same problem in Perl as in other languages. TECO, for instance, doesn't have a nice set of CGI modules to choose from. Any language/library set will work better with particular methodlogies, and less well with others.

      HTTP authentication does not, to my knowledge, facilitate expansion to session data management. This is also the reason for the expiration time. The short duration is simply based on the expected usage patterns. Not using any expiration time would allow the possibility - admittedly remote - of reuse (by regeneration) of the session key. It's simply a means to keep the database 'clean'.

[reply]
        It is the same problem, because the problem as stated didn't ask for which keystrokes to type but asked about the algorithm. The algorithm (as opposed to the implementation, of which 0% appeared in your question) remains the same, regardless of the language used to generate the HTML.

        You are right that HTTP authentication doesn't expand to session data management. Nor does it make coffee. However, your stated problem was "how to keep curious employees from entering data". And while creating sessions is one way of solving it, it doesn't mean you need sessions at all to solve your problem. If, beside keeping curious employees from entering data, you do need sessions, you should have asked about how to make sessions - and not mention the curious employees at all. After all, after solving the session problem, the curious employees have been taken care off.

        Not using any expiration time would allow the possibility - admittedly remote - of reuse (by regeneration) of the session key.

        But that's why you use HTTP level authentication....

        Of course, if someone goes into the trouble of trying to regenerate a session key, would you still classify them as "curious employees stumbling upon the site entering data by accident"? *I* would classify them as "malicious hackers" (or "crackers" for slashdot types).

        -- Abigail

[reply]

Back to Seekers of Perl Wisdom