Are Sessions a Security Risk? (professional discussion)

execute

Ok i have a user auth system, where the user can log in, log out, change password, activation, register, forgot pass etc...
I use to use a system of sessions throughout my website... Where we can find out the username etc thru sessions. However using some different scripts i found, sessions easily forgetting, or not exactly remembering the session for 30 days etc...
this is because i do this when i log on:
set_session_cookie_params(time()+2500000); etc...
so that it remembers the session information.
However it forgets at times... Or doesn't work correctly

The Security issue:
I also found that once a hacker or anything finds out your temp folder, or some insecurity in your website could create a gateway for someone to log into your website without even registering.
Now i have no idea how SSL and stuff work... So anyway i decided to just send an encrypted cookie to the user's computer
then the script will check for the cookie, and it will decrypt it, and find out the username/email/etc...
But are they really a security risk? Isn't this system better? to use a cookie, and database ... for the "Save username and password?" checkbox.????
Are there safer ways to authorize someone?
do sessions have disadvantages with saving info, or easily hacked thru "http://example/index.php?PHPSESSID=523242352352352"
that sort of thing?

LoganK

Once a hacker gains access to someones temp folder, there's nothing to stop them from accesing anything else on that person's computer. IMHO, owning a personal computer is more important than logging into a website using encrypted cookie data from the temp files.

Why are you sending an encrypted cookie onto the user's computer? All session data is stored on the server (I think there's a way of also storing it in a MySQL D😎, so the client has pretty much nothing to worry about. Except for session hijacking or MITM (man-in-the-middle) attacks.

execute

1 reason is because, i been looking into the coding of PHP nuke just to see how they code it. And coming up with my own ideas from it. And it seems they send cookies rather than using sessions. And i dunno maybe it was just my comp but i had problems where my script couldn't access certain sessions when you called them.
So sending them a timed cookie, with encrypted data of the username, pass, and email and stuff rather than using sessions.

But i dunno, but isnt a cookie safer? than a session file? Also what do you mean by : "owning a personal computer is more important than logging into a website using encrypted cookie data from the temp files."

thanks for help 😛

LoganK

Cookies? More secure than sessions? I don't think so. Session are stored on the server, safely where the user can't get to it. Cookies are stored on the client, where the user has free reign to edit and data. Even if you make it encrypted, since it's own the user's machine, they can do anything they want to it. They control it. They can figure out your encryption, change the cookie data, and next time your PHP script inspects the cookie - BAM! - they're dropped into the admin user's session. Number 1 rule of security: NEVER TRUST ANYTHING COMING FROM A CLIENT MACHINE!!! Validate, validate, validate! Security folks cannot stress this enough - once it's on the client, they can do whatever the hell they want with it, and therefore, it cannot be trusted.

What I meant by the comment was that, if I were a hacker (::ahem:: 😃), I would be much more interested in owning someone's box in order to set-up a sniffer and capture passwords, PIN numbers, credit card numbers - basically everything to commit identity theft. Very few hackers will be willing to hack into an end-user's machine, just to steal encrypted cookie data and ultimately log-in to a website. They can go about through much easier means like SQL injection, hidden form value editing, etc.

justsomeone

execute wrote:
I also found that once a hacker or anything finds out your temp folder, or some insecurity in your website could create a gateway for someone to log into your website without even registering.

PHP session handling requires that the session id is passed from page to page via a cookie or a URI variable. PHP will look after the mechanics of this, you just tell it how you want to work. See here for details.

Once you extract the session id from either of the above methods, you then need to validate that session. There are any number of ways to do that, and what makes sense to you is up to you.

For instance if you detect that the last activity on a particular session id was more than 'n' minutes ago, you might want to reauthenticate the user. If you do decide to reauthenticate, you need to decide whether to reprompt for username and password, or just password. Alternatively you might just bin the sesison and create a new one, with reauthentication.

If you detect that the last http request on a particular session was from a different IP address,, you might want to bin the whole session.

If you detect that the browser agent has changed since the last http request on the session, you might want to get suspicious.

etc etc

Session details are stored on the servcer, but the server ID comes from the client. So you always have to rigorously challenge any session ID which comes in.

You may want to limit yourself to only storing session id on the client side, and storing everything else, preferences, history etc on the server side.

If you store everything else on the server side, you need to consider resource implications. Using too manys ession variables can be a waste of server ram. Running to the database for everything can be a waste of time.

Decisions, decisions...

edit: broke the original quote by deleting a bracket :rolleyes:

Roger_Ramjet

Very good paper on session fixation attacks and other security issues

session fixation

LoganK

Aaaah! It's a PDF!! run!!!

Roger_Ramjet

RUN WHERE 😕 They're all around us :eek:

execute

i dunno. I tried using the set_session_cookie_params and stuff whatever... and it wouldn't hold the session after the window was closed. So i find it very inefficient.
The cookie i send with email, id, password, username, is encrypted, ofcourse it can be decrypted by anyone, but how can thewy use that cookie to attack me ? or gain access?

because my script checks for all 4. A malicious user cannot magically use the cookie to guess an admin's username, password, and ID... only his own. EVEN if he learned his own ID... he can't exactly use it to gain access.
i dunno i just find it easier than using session, and wasting my own ram. just make a small function, that decodes the cookie and makes simple variables and then i got the info for the script.

So how would i set a session cookie then? cuz i know sessions, and i used "set_session_cookie_params" or whatever to 30 days, and yet it forgets and stuff. And ofcourse when going from page to page, it would have to check everytime, or it would have to SEND the PHPSession ID using URL variables (GET format) and it would be like: index.php?PHPSESSID=242342f235234d9f888f9745
and someone can easily use that to gain access... Perhaps they have a program that just randomly inserts numbers into the PHPSESSID thing, and maybe they get lucky and find an admins 😛.... Bad example but sorry 😛

would the code be something like:
setcookie("",SID, "", time()+$30days);
(SID = built-in constant for the session id)
and then it reads it or something... i dunno :S
pls help 😛

Roger_Ramjet

??? ??? ???

LoganK

Roger Ramjet wrote:
RUN WHERE 😕 They're all around us :eek:

Run back to DOS - a CLI operating system can't read PDF! 😃

execute

me post been hijacked? 🙁((
:xbones:

i just feel sessions are....mmmm... weak...

Roger_Ramjet

And cookies aren't ???

LoganK

Roger Ramjet wrote:
And cookies aren't ???

Good point. Sessions are more secure than cookies, at least IMHO, but IANAL.

All these acronyms!!! OMG!!! WTF? BBQ!! STFW!! RTFM. STFU. DAFT (thanks Drakla!).