Page 1 of 1

Issues using Cookies

Posted: Sun Sep 23, 2007 1:48 pm
by cpetzol2
I am currently making a simple session manager to manage members of an organization. Most members can only view protected content, but a handful must have administrative privileges. I am a little lost on how to make this secure (enough from them at least). There are no credit card numbers or SSN's, but just some discussions and documents that need to stay private. I am new to this, so, suggestions or harsh criticisms are requested if I am going about something all wrong.

Currently, I make all users log in at the same location...

1a. If it is a general member, they get a session started with privileges to read all the databases on the website.
1b. A cookie is set with a microtime() fingerprint and the sessionID is regenerated.
On each new page request...
1c. Fingerprints in session and cookie must match.
1d. SessionID is regenerated

2a. If an admin logs in, everything above happens, but then they are redirected to a different area with a header() call.
2b. Information must match
2c. New fingerprint is added to both cookie and session
2d. SessionID is regenerated
2e. User is asked for username and password one more time, page request made to control panel
2f. User information is checked
2g. If a match, username and password are stored in a cookie, fingerprints are regenerated, sessionID regenerated.

2h. On each new page request in the control panel, fingerprints are checked. If successful, the username and password stored in the cookie are used to open a new database connection.

This was my original plan. Currently, I am having a problem with the cookies. The first time I add the fingerprint, everything works fine. But when I update the fingerprint, only the session fingerprint is updating, the cookie retains the old value. I have tried many different methods on when and how to code the cookie, but none of my efforts have been successful.

How do I frequently update cookies (where in the code? should I do it before or after sessions? or header calls?)?
Are my header() calls not being used properly, and interrupting my cookies?

Do I even need to fix my cookie problem? Is there a better way to accomplish what I am doing?

Thanks

Posted: Sun Sep 23, 2007 2:28 pm
by Zoxive
2g. If a match, username and password are stored in a cookie, fingerprints are regenerated, sessionID regenerated.
Not a Good idea.

Why are you storing everything in cookies? Why not Use sessions?

Code: Select all

$_SESSION['MYVAR'] = 'Hello';
// Instead of
setcookie("MYVAR", 'Hello');
Why do you keep regenerating the Session?
I can understand for a login and such, but Every page?

Posted: Sun Sep 23, 2007 2:46 pm
by cpetzol2
Why do you keep regenerating the Session?
I can understand for a login and such, but Every page?
Now, thats what I am looking for. I think I am just paranoid from reading what I have about php security. I just thought that using cookies for really important information was safer than sessions. I also assumed that by regenerating the sessionID everytime, it just made it that much safer.

As far as my other uses for cookies, it was just an attempt to not leave sessions hanging by themselves, and synchronizing them with a cookie.

If I am using cookies to much, how else can I keep my sessions safe? Once again, if a member account was compromised, that is not a big deal, but I really would like to make the admin account as secure as possible, hence the extra steps.

Thanks

Posted: Sun Sep 23, 2007 7:04 pm
by Zoxive
Well how sessions work, is it acually sets 1 cookie with a Unique ID.

Using that id it gets all the Data you set for that session which is stored on the Server, and not on the clients computer, making it more secure.

There still is a possibility of someone hijacking that session id. But they have to get access before the session dies.

Posted: Sun Sep 23, 2007 9:11 pm
by VladSun
Zoxive wrote:There still is a possibility of someone hijacking that session id. But they have to get access before the session dies.
and the regeneration of the Session ID makes it even harder - they have to get access before the user goes to another page.

Posted: Sun Sep 23, 2007 9:17 pm
by cpetzol2
So, is regenerating the SessionID on each page a good idea, or is it overkill?

Another question that has come up.... I noticed that when I set the action of some forms =http://www.somesite.com/action.php, my session management code seems to fall apart. But if I set the action of a form =action.php, everything works fine. Any reasons for this? (It seems that all of the session values are being lost between requests using a absolute pathname)

Thanks for the input guys.

Posted: Sun Sep 23, 2007 9:29 pm
by VladSun
cpetzol2 wrote:So, is regenerating the SessionID on each page a good idea, or is it overkill?
I don't think it's overkill ... There is yet another security issue which is solved with session id regeneration - "session fixation".
cpetzol2 wrote:Another question that has come up.... I noticed that when I set the action of some forms =http://www.somesite.com/action.php, my session management code seems to fall apart. But if I set the action of a form =action.php, everything works fine. Any reasons for this? (It seems that all of the session values are being lost between requests using a absolute pathname)

Thanks for the input guys.
I've tested it but I couldn't replay your problem.

Posted: Sun Sep 23, 2007 9:39 pm
by Zoxive
cpetzol2 wrote:So, is regenerating the SessionID on each page a good idea, or is it overkill?

Another question that has come up.... I noticed that when I set the action of some forms =http://www.somesite.com/action.php, my session management code seems to fall apart. But if I set the action of a form =action.php, everything works fine. Any reasons for this? (It seems that all of the session values are being lost between requests using a absolute pathname)

Thanks for the input guys.
It could be "Host" name of the cookie when php is setting it (Maybe with the www or without etc).

Try setting your session.cookie_domain to .somesite.com (Notice the . in front)

Code: Select all

ini_set('session.cookie_domain','.somesite.com'); // Must be called before session_start
Make sure you clear your cookies testing this.
VladSun wrote:and the regeneration of the Session ID makes it even harder - they have to get access before the user goes to another page.
Yes, i guess it all depends on how big the website is.

From what i understand it isn't to large so it would be alright, but nonetheless, it increases server load.
Also posses the possibility of more invalid sessions.

Posted: Sun Sep 23, 2007 9:46 pm
by VladSun
Zoxive wrote:
VladSun wrote:and the regeneration of the Session ID makes it even harder - they have to get access before the user goes to another page.
Yes, i guess it all depends on how big the website is.

From what i understand it isn't to large so it would be alright, but nonetheless, it increases server load.
I don't believe that it will noticeably increase the server load.
Zoxive wrote:Also posses the possibility of more invalid sessions.
What do you mean by that? The main disadvantage of regenerating session id is the "Back button" issue - is it what you have in mind?

Posted: Tue Sep 25, 2007 3:04 am
by cpetzol2
I understand nothing is perfect, or this security section would not exist. I also understand that different implementations of sessions require different procedures. (To the question) Is there a "best practice" for making secure sessions?

Everything I read tells you how to make sessions work, but not necessarily how to make them secure. And on the other side, I have read many techniques on how to manipulate sessions (hijacking, fixation, etc) but how to prevent these attacks seems to be a little over my head.

Does anyone know of any really good info covering the basics of session security?

Thanks a lot to those who have been replying. It has been a lot of help.

Posted: Tue Sep 25, 2007 3:12 am
by cpetzol2
(Sorry for being so inquisitive)

Right now, I am using a cookie to store the "fingerprint" for the session, along with the username and password needed to connect to the databases. Is it safer to store the database info in a cookie or the session? Which is easier to compromise; cookies or sessions?

My reasoning was to store the database info in a cookie, but also require a session to verify the user before the database connection is made. I was thinking that if a session was compromised, all of the important log in information would then be available to the attacker.
If I keep database info in a cookie and a session is exploited, the attacker would still not be able to log in, since no user information is stored in the session, only the fingerprint.

Thanks again

Posted: Tue Sep 25, 2007 8:02 am
by Zoxive
When you use Sessions, it automatically creates 1 cookie, with the session id in it.

Sessions are also stored on the Server, and not the clients computer.

Seeings how the cookies are stored on the clients computer, its very easy to change/view them.
Sessions are more secure because you can't specifically change them, but rather they are Hijacked (Steal the Session Id (cookie) of another user) (very rare but happens).

This is what we have been talking about above.

Posted: Tue Sep 25, 2007 8:07 am
by s.dot
I would just like to make note that the password shouldn't be stored anywhere except where you need it to be stored (database table, most likely). Passing a password around through sessions or cookies (hashed or especcially plain text), is just reducing your security a bit.