Re: Sessions vs Cookies

The Natural Philosopher schreef:
Hugh Oxford wrote:
The Natural Philosopher wrote:

Of course sessions use cookies, Or GET variables, Or POST variables to preserve states, a point which Jerry has never been able to grasp.

sessions are just a coder friendly way of using them. Not a different or intrinsically more secure one.

No, that isn't true.

There is a session cookie which simply allows the server to identify the client and retrieve relevant session data for it. That is the only extent to which sessions use cookies.


I never said more than that. Its simple a way to use one master cookie instead of many little ones.

But a chain is only as secure as its weakest link.. If cookies can be read or forged, it makes little odds whether you have the master key or all the little keys,. The room is open..

Hi Philosopher,

It really DOES matter.
To stick with your master keys/small keys example:
master key: PHPSESSID (data stored on the server, only identified by this key)
small keys: All data is stored in cookies.

Fact: You can change the value for all your cookies, no matter what they hold.

Suppose you store everything in cookies instead of $_SESSION.
Now the visitor can easily change its userid, is_admin, or whatever is stored in them, simply be changing the values of the named ietems listed in that cookie.

Suppose you only send the PHPSESSID (master key): Now you cannot change a thing on the server, even if you have the 'master key'.
The best you can do with it is identify yourself as the 'owner' of the linked sessiondata, but you have no way of directly changing it. Only PHP can do that.

A practical example:
I often use a sessionvariable to identify the admin of my sites.
So somebody logs in (username/password):
1) I check if I can find that info in my database, and also fetch a column named 'isadmin' (holds Y or N) that defines who has adminrights on this particular site.

eg, a typical piece in my loginscript:
$username = $connection->qstr($_POST["username"]);
$password = $connection->qstr($_POST["password"]);
// qstr() makes raw data safe for use in DB (from ADODB)

$SQL = "SELECT userid, isadmin FROM tbluser WHERE ";
$SQL .= "((username=$username) AND (password=$password));";
$RS = $connection->getAll($SQL);
if (count($RS)==0){
// bad login, header blabla, exit
}
$_SESSION["userid"] = $RS[0]["userid"];
$_SESSION["is_admin"] = $RS[0]["isadmin"];

etc..

2) Every page that demands adminrights starts with something like this:
if ((isset($_SESSION["is_admin"])) && ($_SESSION["is_admin"]=="Y")){
// OK
} else {
// No way, get out: header blabla, exit
}

-------------------------------

Now compare the above example (masterkey needed) approach to the one that stores is_admin in a cookie (small keys).

With the cookie you can easily change the cookie named 'is_admin' to Y.
With the masterkey/session approach you cannot change a thing, only the value for PHPSESSID, which will result in an invalid session, thus no entrance on the adminpages.

Bottomline:
-> Using cookies is to store things is totally unsafe: any amateur hacker can change them. So only use a cookie to store unimportant things.
-> Using a session (identified by a cookie via PHPSESSID) is much safer since nobody can change the value of the linked sessionvariables.

For all practical purposes, when somebody intercepts the PHPSESSID of my abovementioned admin, he can wreck havock on my site, since I let the Admin do all kind of things.
But to find the value of that PHPSESSID cookie you need a man-in-the-middle-attack, which is way more difficult that changing the value of your cookie.

Regards,
Erwin Moller


--
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
.

Relevant Pages

  • Re: Sessions
    ... click the link and in aoltest3.php the session variable is visable. ... Registered serializer handlers php php_binary wddx ... session.name PHPSESSID PHPSESSID ... see the PHPSESSID, in a cookie, or in the URL. ...
    (comp.lang.php)
  • Re: [PHP] url rewriting within sessions - confused newbie needs h elp
    ... The first time I load the page, I assume the session is created by ... and the cookie is sent to the browser. ... including a header to set the PHPSESSID cookie; ...
    (php.general)
  • Re: session wont timeout
    ... Maybe this is a session cookie issue? ... client browser there is this one: WSS_KeepSessionAuthenticated Expires: At ... If I kill the session cookie using IE Developer Toolbar, ... possible and IIS would throw another challenge. ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: Is it safe to store user_id in Session?
    ... What I was wondering is how safe it is to store user_id or username or ... session so I do not need to search the database all the time. ... OVERRIDING BASIC SESSION COOKIE AUTHENTICATION ... So what is described in the article only works for bad php scripts. ...
    (comp.lang.php)
  • Chicken and egg issue with Cookie based login?
    ... I have few questions I hope someone can clear up for me with the cookie ... private web server. ... It also says this about the secret key: ... Second, would be an example of the "Session ID" or more general, what is an ...
    (comp.security.misc)