Hey guys, I was scanning my site for security and I noticed that it was possible for non users to send requests and post information, so I decided to put login checks on all information posts. I was wondering if it was a good way to keep a session id that is created by md5(uniqid()); in a session variable $_SESSION['id']=md5(uniqid()); for each user and then store that in a database under active users for that user. Then when a user tries to insert information, verify that their $_SESSION['id'] variable is equal to the one in the database where the username equals their $_SESSION['username']. What are your ideas on this guys? Thanks in advance!
views:
76answers:
3
A:
I've done this before on sites, but it's less of a security measure than it is a feature to allow users to have multiple concurrent sessions. The real key is to check for a valid login token whenever you're performing an operation that requires authorization, and to run your site over HTTPS so that the session cookie can't be hijacked.
Dan Story
2010-03-30 00:15:18
The main idea of this check is so that users who are not logged in cannot submit information to the database. Can you elaborate on login token, and what you mean by running a site over https, how can I tell if I am, is it a server configuration?(sorry I am kind of new to php security).
Scarface
2010-03-30 00:26:24
+1
A:
One solution would be to set a session variable called "loggedin" or something when the user logs in, and make sure that variable is set when you do the database updating (call session_start() before doing the SQL calls, and check the variable in $_SESSION before you send the queries). That way, non-logged in users can't update the database, unless they steal a session from a user already logged in. From what I understand of the problem, this sounds like the simplest solution.
It sounds to me like the solution you came up with is already built into PHP sessions with SESSIONID. A new session in PHP automatically generates a random string identifying your session from the sessions of others. I could be misunderstanding, though.
Ben Torell
2010-03-30 00:38:02
I was worried about people high jacking sessions, so that is why I thought it might be a good idea to do that id check because then I thought it would be harder to for hackers to guess the necessary id needed for their information to be accepted.
Scarface
2010-03-30 00:49:13
The best way to prevent session hijacking is to perform the session over SSL with HTTPS. Otherwise, it's up to the end-user to keep themselves from being hijacked.
Ben Torell
2010-03-30 00:51:09
Sorry, I just saw your comment on Dan Story's post. HTTPS encrypts the data transfer between the user and the server using SSL. If you've every used a banking web site, you'll notice that the URL begins with HTTPS instead of HTTP. This means that they have an SSL certificate that encrypts the data transfer so that would-be hijackers can't see the data going back and forth, including cookies and sessions. This Wiki article may help: http://en.wikipedia.org/wiki/HTTP_Secure
Ben Torell
2010-03-30 00:54:40
And Dan's bit about the "login token" is the same thing as what I suggested regarding setting a $_SESSION variable. All it is is some piece of information stored somewhere that lets you check whether the current user is logged in or not, most conveniently in the $_SESSION var.
Ben Torell
2010-03-30 00:57:28
I think everyone should check this for validating form input by the token technique to prevent csrf attacks http://shiflett.org/articles/cross-site-request-forgeries
Scarface
2010-03-30 05:19:52
@Val whata nonsense. who said it's easy to spoof? Non-users just wouldnt have a $_SESSION['username'] varibale set.
Col. Shrapnel
2010-03-30 07:05:00