session security tweaking (not syntax)

@JDM71488Nov 26.2005

i have a lot of projects that i would like to distribute, but only if i knew they were secure. i have been reading online for some time, and just mainly want to share and get info with you all on this topic. i read some other posts relating to the topic, but none of them seemed to really hit the spot…

~~[B]~~my scenario[/B] – correct, add, subtract info as you see fit.

~~[list=1]~~

~~[*]~~

if not logged (session variable) enter username and password

~~[*]~~

data is checked for injection and fails if found

~~[*]~~

passwords are checked with them being one-way encrypted in db

~~[*]~~

username is stored in session variable

~~[*]~~

user navigates thoughout my site

~~[*]~~

session is destroyed upon logout or browser exit

[/list]

i guess i am just curious as to if i have any security holes in there?

if the session wasn’t deleted, it would be stored on the server. so if someone got the session_id, then they could replace the generated one with the one that holds all of the previously logged users information. mainly the variable that held true that they were logged in, right?

to post a comment

PHP

16 Comments(s) _↴

@Daniel_TNov 26.2005 — #Since it is possible to manipulate session cookies, you need to check if the user is logged in on each page load. To do this, store the user's password (already encrypted) in a session variable and check it against the one in the DB each time the page is loaded (if match, then continue with loading page).

@JDM71488authorNov 26.2005 — #i like your response. would this be more efficient than throwing $_SESSION['logged']=true, and checking that on each page? if so, could you explain why, please? ?

@NogDogNov 26.2005 — #My understanding is that the only thing that gets stored on the client is the cookie with the session ID. Any $_SESSION variable you save is stored on the server side. Therefore, I don't see the benefit of storing the password over any other identifier in the $_SESSION array. (I don't see anythig wrong with it, either, just not why it would be particularly better than anything else.)

@JDM71488authorNov 26.2005 — #well for a login, if i do the following will i be secure? besides brute force?

[list]

[*]authenticate the login

[*]set $_SESSION['logged'] = true

[*]check $_SESSION['logged'] on each page

[*]logout will do the following, overkill ?

[list]

[*]$HTTP_SESSION_VARS = array();

[*]unset($HTTP_SESSION_VARS);

[*]session_destroy();

[/list]
[/list]
but, when the user is logged in on my website, and then lets say they go to google, the session is never terminated... how can i automatically terminate them?

http://www.webkreator.com/php/concepts/advanced-session-security.html

i read a lot of articles about session hijacking, but if the session information is not stored on the server, then there would be nothing to hijack right?

@Stephen_PhilbinNov 26.2005 — #Mr Reace here is right. The only thing that is stored on the client machine is the session hash key, nothing else. As for unsetting a session when a user goes to a different page, well you can't really. Besides, it'd be annoying as hell if you did. Session timeouts handle that stuff well enough.

I'm doing a CMS that has a multi-user system as part of it. I handle it by having only two scripts in the whole thing capable of creating a user object: the user login page, and the staff login page. Each level of user is an extension of its subclasses too, it goes like:

Administrator class extends -> Staff class extends -> User class

That way, all user object are an instance of at least the user class. Then when I want to check just for is someone is logged in I check whether the session holds an object and that that object is an instance of at least the user class. Like so:

[code=php]
 $user = NULL;
 
 session_start();
 if(isset($_SESSION['user']))
 {$user = $_SESSION['user'];}
 
 if(!($user instanceof user))
 {/* chuck 'em out */}
 [/code]

Like I said, only the login scripts can build the user object and only if they are given the required user name, password and ID key. So unless they logged in properly, they're going nowhere.

@NogDogNov 26.2005 — #I would use the following from http://www.php.net/session_destroy :

[code=php]
 <?php
 // Initialize the session.
 // If you are using session_name("something"), don't forget it now!
 session_start();
 
 // Unset all of the session variables.
 $_SESSION = array();
 
 // If it's desired to kill the session, also delete the session cookie.
 // Note: This will destroy the session, and not just the session data!
 if (isset($_COOKIE[session_name()])) {
 setcookie(session_name(), '', time()-42000, '/');
 }
 
 // Finally, destroy the session.
 session_destroy();
 ?>
 [/code]

Also, you might want to consider setting session.use_only_cookies in you php.ini configuration (and consequently require that users have cookie support enabled on their client).

Lastly, you can utilize SSL to prevent "sniffers" from intercepting session IDs.

@JDM71488authorNov 27.2005 — #stephen, i like the functionality of your classes... but in general, i think you all were going in the wrong direction than what i was looking for.

when a session is started, the session_id is stored on the server, i guess in a file, and any $HTTP_SESSION_VARS variable will be stored under that session id, im guessing?

if there is no way to delete the session, then it is possible for someone to sniff the session_id and use it on my site to pull $_SESSION['logged'] = true; right?

so, using sessions to store only $_SESSION['logged']=true; is useless, right?

so, sessions without cookies are useless? im sorry for all of the confusion.

@bokehNov 27.2005 — #if there is no way to delete the session, then it is possible for someone to sniff the session_id and use it on my site to pull $_SESSION['logged'] = true; right?[/QUOTE]The session id must travel from the client to the server in some form or other, either as a cookie or query string. It is possible to delete the session array on log out with unset() but that is no help if someone has [I]sniffed[/I] the SID and is using it while the session is still active. The only way to protect against this is to use an SSL connection as pointed out by Nogdog. With SSL everything including file path, query string and cookies are encrypted.

@JDM71488authorNov 28.2005 — #all encrypted passwords are stored in DB with one-way encryption.

[B]scenario 1[/B] Daniel T suggested
[list]

[*]encrypted password is stored in session variable

[*]each page checks it against one in db

[/list]

now, if someone sniffs the sid, wouldn't they obtain that session variable and be able to access the protected pages?

[B]scenario 2[/B]
[list]

[*]script dies if cookies are disabled (or use_only_cookies)

[*]after successful login, store encrypted password in cookie

[*]check cookie value against db on each page

[*]cookie is deleted after browser closes

[/list]

with scenario 2, the sid is practically useless. could this be hacked? there would be no way to obtain the cookie, right?

i don't know where to begin with SSL... i've heard of it, but never looked into it. it sounds pretty rough.

@SheldonNov 28.2005 — #I dont set the password in my sessions, i set other things as sessions, username, real name ,email, so forth so on, but hte only thing i check for is

[code=php]if(session['logged' == "yes"){ /*sweet*/ }else { /*Go away now*/ }[/code]

The chance you are going to get hacked, is so small, and how is a client side script going to set a session, unless you give people acces to ftp/upload php files on your server or you post your mySQL username and password and remote database address on sites like this as some idiots do, you are overkilling everything.

Unless you tend to do some sort of $$ transactions on your site, then use SSL. No worries.

These are my views, not deffinitly right at all.

@JDM71488authorNov 28.2005 — #thats cool sheldon. when you say you store things with sessions, do you even use cookies at all?

@SheldonNov 28.2005 — #only for the remember me option, then i only store the username and do an

if(logged in(no)) then isset(cookie(yes)) = login / else do nothing

in every page, nice and quick with not too much server load on.

so one cookie per site, if i want some users input to be stored ill put it on their database, more permanat and it doesnt matter if the user come from any computer.

@JDM71488authorNov 28.2005 — #hmm. i always have done the <?php if($_SESSION['logged']==true)....... ?> as well, but i still don't like the idea of not being able to erase the session data (specifically logged=true) on the server.

i can set cookies to erase themselves, and i don't even think there is a way for a person to intercept the cookies? (i think) so, the only downfall to this is people have to have cookies set...

ugh, idk... i guess i'll just stick with the same method like you.

@SheldonNov 28.2005 — #sessions are erases as soon as the user closes the browser, you could always write a jacascript script that onexit from http://domain.com print"<?php session_start(); session_destry(); ?>";

I cant remember if there even is a js function for it, but i remember somethng like it from the days when i used to use JS more often.

But as i think Bokeh said, sessions time out! Its not that much of an issue else it would be a bigger problem.

@bokehNov 28.2005 — #only for the remember me option, [/QUOTE]That is a bit confusing because of course the automatic session cookie is set. Sheldon is saying here that he doesn't set any additional cookies.

@SheldonNov 28.2005 — #That is a bit confusing because of course the automatic session cookie is set. Sheldon is saying here that he doesn't set any additional cookies.[/QUOTE]

Ah yes you are correct, Bokeh you did it again. Other than the automatic cookie i mostly only set a cookie for a remember me login option. I guess there has been the odd instance when i maybe have used them, but not for log in scripts.

Also in #PHP _↴

can i grab / scrap the content of any web page Site Navigation with Selected Feature...Need Help PHP works in F.F. and not in I.E.?

Success!

Help @JDM71488 spread the word by sharing this article on Twitter...

Tweet This

session security tweaking (not syntax)

16 Comments(s) _↴

Also in #PHP _↴

Success!

Social

Version

session security tweaking (not syntax)

16 Comments(s) ↴

Also in #PHP ↴

Success!

The web is an endless sea of information. Don't miss the boat... Subscribe!

Social

Version

16 Comments(s) _↴

Also in #PHP _↴