Sessions and security

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

User avatar
MarK (CZ)
Forum Contributor
Posts: 239
Joined: Tue Apr 13, 2004 12:51 am
Location: Prague (CZ) / Vienna (A)
Contact:

Sessions and security

Post by MarK (CZ) »

Hi all!

This has maybe already been discussed but I can't find the thread.
So the question: can sessions be hacked in some way? in other words, is it safe enough to rely just on session $_SESSION["logged"] instead of matching the logging values with DB every time a script runs?

Thx in advance :)
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

Sessions can be hijacked, especially if your on a shared hosting plan. However, it is unlikely. Although I would not suggest giving ultimate access to your website through a simple $_SESSION['logged']. Have the user loggin, and have seperate functions to

1) validate the user
2) get their access level

Often, I design my applications to to follow these types of routine checks.

Code: Select all

//check they are logged in, and have sufficient access
if ($_SESSION['logged'] && ($user->get_perm($_SESSION['uid'])) >= 3)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Remember: no session is safe if the session cookie is stolen. (beware of the cookie monster). This is a very common attack when it comes to cross-site scripting: steal the cookie.
User avatar
MarK (CZ)
Forum Contributor
Posts: 239
Joined: Tue Apr 13, 2004 12:51 am
Location: Prague (CZ) / Vienna (A)
Contact:

Post by MarK (CZ) »

Ambush Commander wrote:Remember: no session is safe if the session cookie is stolen. (beware of the cookie monster). This is a very common attack when it comes to cross-site scripting: steal the cookie.
How does that work? Could you give me more info please? thanks! :)
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

MarK (CZ) wrote: How does that work? Could you give me more info please? thanks! :)
Sure: Use two web-browsers. Open your site in Firefox, and login. While logged in, copy the cookie for your site.

Then open internet explorer, go to the same site, and paste the cookie into your cookie folder.

Now access the site, and notice that you are logged in. Thats a 'replay attack'.

To be scared, realize that I could take your cookie, and do the same from my computer. Or a library computer.

Thats why logins should be challenge-response with a one-time pad. Send the client (the user) a unique value, and store it in a db. Then have the user send you a hash of their password and that unique value (one-time pad). Finally, compare it on the server with a hash of the unique value and their password. If it matches, they get in. If it doesn't, they don't. In both cases, delete the one-time hash from the db.

Simple.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

But not necessarily the most convenient or efficient. Foremost, in order to prevent our "Cookie Monster" from stealing the cookie of the password hash, you'd need to type in the password EVERY TIME.

Security is always a balance between usability and security.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

Ambush Commander wrote:But not necessarily the most convenient or efficient.
Agreed.
Ambush Commander wrote:Foremost, in order to prevent our "Cookie Monster" from stealing the cookie of the password hash, you'd need to type in the password EVERY TIME.
Yup.
Ambush Commander wrote: Security is always a balance between usability and security.
Nope: Security is always security.

The designer/programmer is the one that has to balance security and usability, and often, they aren't fundamentally in conflict:

http://usablesecurity.com/2005/03/12/fu ... -conflict/
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Hmm... I never thought of it that way. Interesting.

But for our login authentication, there is a conflict between usability and security (as the blog stated). ;)
AGISB
Forum Contributor
Posts: 422
Joined: Fri Jul 09, 2004 1:23 am

Post by AGISB »

I find it totally unnecessary to store the user credentials in a cookie in any way.

Simply check the username and password once. Store the session, ip and username in a db including a timestamp. On any site call update the entry with the current timestamp. If no entry is found with either ip and username or session and username reauthenticate. If the timestamp is older than e.g. 15 minutes reauthenticate.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

Ambush Commander wrote:Hmm... I never thought of it that way. Interesting.

But for our login authentication, there is a conflict between usability and security (as the blog stated). ;)
Agreed.

The article really flipped my world view a bit when I read it, so when people mention the fundamental conflict, I like pointing it out. Despite being in information security for nearly a decade now, it was a very different take on security and usability for me. (Fresh ideas these days are worth their weight in gold, in my opinion).

But yes, authentication is definitely one where you have to pick your poison: easier, or more secure.
sumeet
Forum Newbie
Posts: 15
Joined: Mon May 23, 2005 3:55 pm
Location: Hyderabad
Contact:

Post by sumeet »

I m making a paper uploading portal so worried abt its security ... i m using Sessions for it and keeping a check variable in session and checking its value on every page ...any suggesions to make it secure ... One more thing i wanna add here is that the session id generated by PHP is not secure .. as if i opened two logins in diff tabs of firefox it generated same id .. can anyone explain me y it is so ??
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

sumeet wrote:One more thing i wanna add here is that the session id generated by PHP is not secure ..
It can be. You misunderstand how the function works.
sumeet wrote: as if i opened two logins in diff tabs of firefox it generated same id .. can anyone explain me y it is so ??
Yes, because you misunderstand tabs and the nature of authentication.

In simple terms, you login to a site. Once you do, you've established a session with the server. All subsequent tabs inherit that session. If you open a new tab, thats still "you", and it still has that session. Thats not insecure. If your app correctly destroys a session before creating a new one, the second tab would end up with a new session, and the first tab would have an invalid session.

If your app isnt destroying a session before creating a new one, thats an application/coding error.

Tabs are meant to share/reuse/inherit the authentication from the previous tab - otherwise every tab you opened would require you to relogin, which would be incredibly obnoxious and useless.
User avatar
MarK (CZ)
Forum Contributor
Posts: 239
Joined: Tue Apr 13, 2004 12:51 am
Location: Prague (CZ) / Vienna (A)
Contact:

Post by MarK (CZ) »

Roja wrote:If your app isnt destroying a session before creating a new one, thats an application/coding error.
How is that done? I still don't get the point where can I prevent anyone from getting around the sessions. Sorry about my ignorance of the problem :P
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

PHP has sessions built in, and eliminates most of the work for you.
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

MarK (CZ) wrote:
Roja wrote:If your app isnt destroying a session before creating a new one, thats an application/coding error.
How is that done?

Code: Select all

session_destroy();
session_start();
MarK (CZ) wrote: I still don't get the point where can I prevent anyone from getting around the sessions. Sorry about my ignorance of the problem :P
I don't understand your question. What don't you understand?
Post Reply