Issues using Cookies
Moderator: General Moderators
Issues using Cookies
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
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
Not a Good idea.2g. If a match, username and password are stored in a cookie, fingerprints are regenerated, sessionID regenerated.
Why are you storing everything in cookies? Why not Use sessions?
Code: Select all
$_SESSION['MYVAR'] = 'Hello';
// Instead of
setcookie("MYVAR", 'Hello');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.Why do you keep regenerating the Session?
I can understand for a login and such, but Every page?
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
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.
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.
and the regeneration of the Session ID makes it even harder - they have to get access before the user goes to another page.Zoxive wrote:There still is a possibility of someone hijacking that session id. But they have to get access before the session dies.
There are 10 types of people in this world, those who understand binary and those who don't
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.
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 don't think it's overkill ... There is yet another security issue which is solved with session id regeneration - "session fixation".cpetzol2 wrote:So, is regenerating the SessionID on each page a good idea, or is it overkill?
I've tested it but I couldn't replay your problem.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.
There are 10 types of people in this world, those who understand binary and those who don't
It could be "Host" name of the cookie when php is setting it (Maybe with the www or without etc).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.
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_startYes, i guess it all depends on how big the website is.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.
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.
I don't believe that it will noticeably increase the server load.Zoxive wrote:Yes, i guess it all depends on how big the website is.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.
From what i understand it isn't to large so it would be alright, but nonetheless, it increases server load.
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?Zoxive wrote:Also posses the possibility of more invalid sessions.
There are 10 types of people in this world, those who understand binary and those who don't
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.
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.
(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
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
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.
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.
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.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.