in reply to Cookie not being set

Have you tried other browers? Are you using IE6?

IE6 with the default security setting (or anything above Low Secuity) will reject cookies from site without a P3P policy and P3P CPP headers.

If you do not have a P3P policy (an unapproved standard deemed necessary by our malevolent dictator in Redmond) for your site you should (or your users will experience the problem I stated above). You can readup on P3P at W3C. W3C also provides a P3P Validator

As a side note - do not store usernames and passwords in a cookie, this is a security hole (that has been experienced at some well-know sites :) ). You might want to setup a sessionid for that user and reference (and expire) that id

Ovid's excellent CGI programming course addresses cookies and security concerns



grep
Just me, the boy and these two monks, no questions asked.

Replies are listed 'Best First'.
Re: Re: Cookie not being set
by caedes (Pilgrim) on Jun 24, 2002 at 08:04 UTC
    This isn't entirely accurate. Only third party cookies without a P3P are blocked at the default setting for IE6. It takes a setting of "High" to block 1st party cookies (what this example would be) for a site without a P3P.

    -caedes

[reply]
(joshua) 2Re: Cookie not being set
by joshua (Pilgrim) on Jun 24, 2002 at 04:44 UTC
    do not store usernames and passwords in a cookie, this is a security hole
    Could you explain why or point me to a node to look at?
    You might want to setup a sessionid for that user and reference (and expire) that id
    How would be a good way to go about doing this.

    Thanks
    Joshua

[reply]
      Here is one node and another that hits closer to home. Other than that I imagine you can search.

      As for you session question - if you are using Apache, Apache::Session IIRC will handle it all for you. If not - a simple setup would be session table in your DB with username, timestamp, and session id. Then check for that sessionid (passed either as a param or cookie) and see if it expired



      grep
      Just me, the boy and these two monks, no questions asked.
[reply]

      There are several reasons why this is a security hole.

      • Assuming this is not sent over SSL, someone could sniff the traffic and, since this is sent in plaintext, they can see your user's passwords.
      • This is usually stored on the user's computer, so someone else with physical access to their machine can get this data.
      • Cross-site scripting attacks can often read cookie data and send it somewhere else, thus allowing yet another way to compromise the user's data.

      Never fear, these things become second-nature after you work with the Web for a while :)

      Cheers,
      Ovid

      Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[reply]
        I don't want to turn this node into a discussion on web security but...

        Here's my setup:

        • Password is stored encrypted using the crypt function w/ a random key in a file on the server outside of the public-viewing.
        • User enters pass in a form.
        • Password is sent to the server in plaintext (not good)
        • Server encrypts the user's entered password and makes sure it matches the one in the file
        • Server sends cookie to browser that contains encrypted password
        • Each time the user wants to go to a different part of the admin, the server checks the password in the cookie to make sure it's correct.
        I know this doesn't sound very secure, so I'll look into some of the other methods discussed.
        Never fear, these things become second-nature after you work with the Web for a while :)
        I'm kind of seeing that...I've come far since I started doing CGI, but I know I have a lot more to learn.

        Joshua

[reply]

In Section Seekers of Perl Wisdom