Jump to content
Larry Ullman's Book Forums

Chapter 12: More Security Recommendations


Recommended Posts

I am trying to understand this bullet point on page 368:

 

"Watch how database references are used. For example, if a person's user ID is their primary key from the database and this is stored in a cookie (as in Chapter 11, "Cookies and Sessions"), a malicious user just needs to change that cookie value to access another user's account".

 

Page 349 tells us that when a session is created, it also creates a browser cookie.

 

For example when tracking user activity, checking to see which user modified a table.

 

Here some methods in the book:

 

 

(1.) A solution on page 358:

 

Page 358 provides a method for improving sessions security by checking if the $SESSION['agent'] is set, and then also checking if the the $_SESSION['agent'] matches the $_SERVER['HTTP_USER_AGENT']

 

(2.) A solution on page 360:

 

Page 360 introduces session_regenerate_id(), which provides a new session ID.

 

MY QUESTION:

 

While these are nice methods to use, should we not store a users ID like so?

 

$_SESSION['user_id'] = $data['user_id'];

 

Here, the users primary ID is stored into the session. I am thinking of plenty scenarios where this is necessary like tracking user activity. I have already built a nice database design and script that uses the users primary id as a way to track their activity.

 

Is this the right way to do it? Is this unsecure?

 

Thanks,

Mark

Link to comment
Share on other sites

Yes, if you need the iD. store it. The problem with Using user id is that everyone knowns numbers. If you use usernames or email adresses, you won't have that problem.

 

The thing with user agent is to force a new login if the users switches agent. That'll probably never happen for the legit user, so it's more like a security. Chanses are, if it's not the same agent, it's someones hacking

  • Upvote 1
Link to comment
Share on other sites

Yes, if you need the iD. store it. The problem with Using user id is that everyone knowns numbers. If you use usernames or email adresses, you won't have that problem.

 

Yes, in my web app I need the user_id both stored in a session and database. I dont understand why user_id will be a problem but usernames and email addresses won't be a problem. Don't they have same level of vulnerability if stored in a session?

Link to comment
Share on other sites

Yes, if you need the iD. store it. The problem with Using user id is that everyone knowns numbers. If you use usernames or email adresses, you won't have that problem.

 

The thing with user agent is to force a new login if the users switches agent. That'll probably never happen for the legit user, so it's more like a security. Chanses are, if it's not the same agent, it's someones hacking

 

Yes and Admin on a major site can have user_id of 0 or 1 in the database, so people know what to look for. I like the ENUM data type so you that way you can distinguish between a member and the administrative side.

Link to comment
Share on other sites

Yes, in my web app I need the user_id both stored in a session and database. I dont understand why user_id will be a problem but usernames and email addresses won't be a problem. Don't they have same level of vulnerability if stored in a session?

 

Well you could think of i this way, the less information you can provide a hacker the better. They will already have the user name to work with, and if you give them a user_id also they have two.

Link to comment
Share on other sites

Doesn't the session create some sort of identifiable cookie on the user's system though?

 

My question also. The session automatically creates a cookie correct?

 

Yes and Admin on a major site can have user_id of 0 or 1 in the database, so people know what to look for. I like the ENUM data type so you that way you can distinguish between a member and the administrative side.

 

I've never used ENUM, great suggestion. But if storing a user_id in a session is OKAY, then I would rather proceed that way.

Link to comment
Share on other sites

Yes, the session creates a cookie which stores the session ID. This is safe for the user to see and it's rather difficult to hack.

 

The problem is simply this: if a site just stores the user_id in a cookie, it's very, very easy for anyone to edit that cookie and change it from say, 1, to 2. Now the user is pretending to be someone else. But if that user_id is stored in a session, one user can only pretend to be another user if they can falsify the session ID. That session ID is 32 hexadecimal characters, which is unlikely to be hacked, and not worth the effort.

 

I think the ENUM issue is separate and unrelated to this specific issue.

Link to comment
Share on other sites

Yes, the session creates a cookie which stores the session ID. This is safe for the user to see and it's rather difficult to hack.

 

The problem is simply this: if a site just stores the user_id in a cookie, it's very, very easy for anyone to edit that cookie and change it from say, 1, to 2. Now the user is pretending to be someone else. But if that user_id is stored in a session, one user can only pretend to be another user if they can falsify the session ID. That session ID is 32 hexadecimal characters, which is unlikely to be hacked, and not worth the effort.

 

I think the ENUM issue is separate and unrelated to this specific issue.

 

Great thanks I fully understand now in regards to my question. Since we are on the discussion of sessions(), I have an extra question below:

 

My web application works great, except the session never expires if left overnight I am still in the session because I have not logged out. But I would like a session to expire based on idleness length of time.

 

I have been searching chapter 11 for a way to designate an expiration on a session() if the user has been idle for a specified amount of time. I have forgotten where this line of instruction is located now, or if it only applies to set_cookie().

 

Thanks,

Mark

Link to comment
Share on other sites

If you're testing this locally, without a lot of traffic, your sessions may not be expiring because garbage collection isn't kicking in often enough. Here's how it works: with every invocation of PHP, there's an X% chance that garbage collection will be performed. The X is set in the configuration file, but I think is 1 by default. This means that 99 requests out of 100 ARE NOT triggering garbage collection. Furthermore, these would have to be requests that aren't also extending your session. If you're testing locally, or an a server without any traffic, you're probably just not triggering it.

Link to comment
Share on other sites

If you're testing this locally, without a lot of traffic, your sessions may not be expiring because garbage collection isn't kicking in often enough. Here's how it works: with every invocation of PHP, there's an X% chance that garbage collection will be performed. The X is set in the configuration file, but I think is 1 by default. This means that 99 requests out of 100 ARE NOT triggering garbage collection. Furthermore, these would have to be requests that aren't also extending your session. If you're testing locally, or an a server without any traffic, you're probably just not triggering it.

 

Exactly what I was looking for Larry. Page 354 explains "Garbage Collection". I am running my site on a server that does not receive a lot of traffic, it is a management tool for just a few internal admins, so garbage collection isn't kicking in.

 

This section of the book explains it well, just now found it - thanks!

Link to comment
Share on other sites

 Share

×
×
  • Create New...