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

I am setting a cookie using CGI.pm in the first script, retrieving the value and using that in subsequent scripts. 

$cookie = $query->cookie( 
-name => 'newcookie',                    
-value => $newcookie,        
-domain  => '.xyz.com',
-expires => '',    
-path => '/'
);

[download]

If I set -expires => 'somevalue', I see the cookie in text format in the folder that has all the cookies.. (for example, C:\Windows\Cookies )but if I don't set a value for -expires => '', I don't see the cookie saved to the hard drive.

Is there any other way a user can find out the cookie, if -expires is not set (as it doesn't save the cookie as a text file)? Does the cookie expire when the browser is closed? Is this a safe way to pass encrypted password to subsequent pages?

Replies are listed 'Best First'.
Re: Hiding cookies from users
by Joost (Canon) on Jul 05, 2006 at 14:01 UTC
[reply]
Re: Hiding cookies from users
by derby (Abbot) on Jul 05, 2006 at 14:08 UTC

    What you're describing is the difference between a permanent cookie (has expiration date in the future) and a session cookie (expires when the browser closes ... sometimes). Most browsers (ok - firefox) allow for the inspection of permanent cookies as well as session cookies. Even if they didn't, you should never assume anything sent to a client *cannot* be seen by the client (someone can write their own client).

    You're just touching the surface by encrypting the password (even encrypted, how can you prevent man-in-the-middle session hijacking). Check out the W3 FAQ section on Cookie Security ... (but be cautious about using IP address in your scheme since it can change during a session if a user is behind a big proxy server).

    -derby
[reply]

      Thanks for the response

      I have to validate the password against the one stored in a flat file. (No database involved)

      I am not sure of a better way to pass the encrypted password from one page to another other than cookies.

      I tend to think that cookies are better than hidden fields or writing to temp file and retrieving the value each time.

      Any suggestions?

[reply]

        I have to validate the password against the one stored in a flat file. (No database involved)

        DBI and DBD::SQLite are pretty easy to install, and SQLite is a self-contained database that uses a flat file for its data storage. If you feel yourself growing beyond the point where flat files start to become cumbersome, migrate to a database. If you haven't got the ability to install a real database, install SQLite. It's a pretty simple solution, self-contained in a Perl module.

        Next point: Don't pass the encrypted password from session to session. Pass a hashed session ID. Validate password once, then maintain an MD5 hashed session ID.

        Look at CGI::Session's documentation. It helps to wrap up these loose ends; it facilitates the use of a database (including SQLite), and via CGI::Session::ID::MD5 provides a means of handling hashed session identifiers.


        Dave

[reply]
        Whoa, /never/ pass the password, encrypted or otherwise, via the cookie. Create an extremely valid, hard to guess and brute force token, and pass that around. Tie it back to the user. Passing the user's credentials around is begging for a security issue if it's a public interface.
[reply]
Re: Hiding cookies from users
by simon.proctor (Vicar) on Jul 05, 2006 at 14:59 UTC
    Update:Added page number in owasp section at bottom

    You shouldn't be passing an encrypted password to subsequent pages. All you should be storing, if anything, is a session identifier. You can store this in the url, a hidden field in a form (.NET for example), a query string or a cookie. You can encrypt it too if you like ;).

    All your pertinient info can then be stored/accessible to your web server in some form . It might be an encrypted record in a session file or record in a db (or whatever). Though of course, you then need to plan how these records expire, what happens if someone were to gain access to them (etc).

    Using any kind of session variable/identifier has its positives and negatives. Cutting and pasting that identifier, for example, may allow someone else to hijack a session. However, at least that session identifier does not contain any information and it doesn't matter if it is stored on disk (etc). It also means you are free up to store larger amounts of info without worring about the size or number of cookies you set.

    As an aside, this is more a question of web security. With this in mind, I really do recommend you read up on this via the Open Web Aapplication Security community site. They have a set of PDF guides PDF for distribution that are worth reading. The download page is here.

    Just some thoughts ;).

    Update: page 157 in the current draft covers sessions and best practise. Check it out!

[reply]

      Thanks for links.

      I will check them out

[reply]
Re: Hiding cookies from users
by vagnerr (Prior) on Jul 05, 2006 at 13:59 UTC
    If the expires data is not set on a cookie the browser only stores the cookie data in memory not to disk, it "expires" when the session ends, Ie when the browser is closed


    ___________
    Remember that amateurs built Noah's Ark. Professionals built the Titanic.
[reply]

Back to Seekers of Perl Wisdom