Nice Framework - but the SESSIONS are scaring me.

[eluser]Xeoncross[/eluser]
Well, I have been using a home grown framework (about 300K) for a while and so I am used to loading times within the 60-200ms range. Recently I got in a fight with abstracting over PDO, and so I decided to try Zend Framework because they had such a beautiful DB object AND was built by the company that is sooooo involved with PHP.

After this last week of playing with it am throughly disgusted with the amount of RAM ZF uses just to load the system. 4MB & 3sec to show a single (static) view in a template (Zend_layout) with no DB or anything. That's sad. (But the extra code libraries like gdata are awesome.)

So after reading lots of benchmarks online I found that CI was running about 2x-3x the speed of the ZF. So you guys have my attention now. ;-)

However, after reading over this system I am unnerved to discover that CI ACTUALLY STORES DATA IN COOKIES! This point alone makes me question the whole rest of the system. Raw (even encrypted) Data in Cookies are of the devil.

Why in the world isn't the default set to use sessions with only a single session handle given to the user?

Now I have seen some libraries that add this - but the fact that it isn't the default worries me.

http://ellislab.com/forums/viewthread/84429/
http://codeigniter.com/wiki/KNDB_Session/

Why are there DB specific functions like "mysql_fetch_assoc" in the recommended session lib "KNDB_Session"?

Also, it looks like you have to go through CI to get to the data that should be in the $_SESSION array? Here is a very simple procedural example of what the PHP default would look like for a DB table for sessions.

Code:

<?php
/*##############################################
## SESSION FUNCTION FILE
## This file contains the functions that will over-ride
## PHP's default session handlers. (Usually files in the /tmp dir)
################################################
## Functions for storing the $_SESSION[] values in a database
## instead of the /tmp dir. Because anyone can read the data
## in a shared hosting environment with files in the /tmp. Plus,
## if you have a Shared host - chances are your server changes
## every time someone loads a page. Which means that your sessions
## end up spread across sever servers!
##
## CREATE TABLE markit_sessions(
## id varchar( 32 ) NOT NULL ,
## access int( 10 ) unsigned,
## DATA text,
## PRIMARY KEY ( id )
## );
##
## +--------+------------------+------+-----+---------+-------+
## | Field  | Type             | Null | Key | Default | Extra |
## +--------+------------------+------+-----+---------+-------+
## | id     | varchar(32)      |      | PRI |         |       |
## | access | int(10) unsigned | YES  |     | NULL    |       |
## | data   | text             | YES  |     | NULL    |       |
## +--------+------------------+------+-----+---------+-------+
##
################################################*/

//ini_set('session.name', 'CISESSID');

//DB is already open so just return TRUE
function session_open() { return true; }


//DB will close on it's own so just return TRUE
function session_close() { return true; }


//Read data from the given session $id
function session_read($id) {
    
    $db = db::current();
    $cx_config = cx_config::current();
    
    $sql = 'SELECT data FROM `'. $cx_config['db_info']['prefix']
         . 'sessions` WHERE id = \''. $db->escape($id). '\'';
    
    //If the query was succsesful (in "running" - not in "finding" anything)
    if ($db->query($sql)) {
        //if the query found something
        if ($db->found_rows()) {
            //return the 'data' value
            return $db->fetch_value();
        }
    }
    
}


//Write Data to a session
function session_write($id, $data) {
    
    $db = db::current();
    $cx_config = cx_config::current();
    
    //Destroy the row if it exists (if we change "REPLACE" into "INSERT" for future DB's)
    //For MySQL and SQLite, "REPLACE INTO" is fine for now.
    //_destroy($id);
    
    //REPLACE INTO doesn't work with with some databases so we would need to use INSERT INTO
    $sql = 'REPLACE INTO `'. $cx_config['db_info']['prefix']. 'sessions`'
         . 'VALUES  (\''. $db->escape($id). '\', \''. $db->escape(time()). '\', \''
         . $db->escape($data). '\')';
    
    return $db->query($sql);
    
}


//Kill a session
function session_kill($id=null) {
    
    $db = db::current();
    $cx_config = cx_config::current();

    return $db->query('DELETE FROM `'. $cx_config['db_info']['prefix']
                      . 'sessions` WHERE id = \''. $db->escape($id). '\'');
}


//Garbage collection (clean old sessions)
function session_clean($max) {
    
    $db = db::current();
    $cx_config = cx_config::current();

    return $db->query('DELETE FROM `'. $cx_config['db_info']['prefix']
                    . 'sessions` WHERE access < \''. $db->escape(time() - $max). '\'');
}


//Save our New DB session handler over the default "file-based" session storage
session_set_save_handler('session_open',
                         'session_close',
                         'session_read',
                         'session_write',
                         'session_kill',
                         'session_clean')
    or trigger_error('Could not set the session handler', E_USER_ERROR);



// The following is only to work around a PHP 5.2.X bug:
// Ensure SESSION data is saved before the $db object is destroyed.
// http://us2.php.net/session_set_save_handler
register_shutdown_function('session_write_close');

?&gt;

So I don't really know where I am going with this - but I want to know if anyone has anything to add to the way CI handles stored user data.

So any help in getting into the CI mindset would be appreciated. ;-)


EDIT: The DB2_session class looks better...

[eluser]zeratool[/eluser]
you can try this one :

http://codeigniter.com/wiki/Native_session/

[eluser]nevsie[/eluser]
surely this depends on your needs and why you wish to put into the session cookie... if it does need to be secure then don;t use the default, but use the DB session with a little extra setup time..

[eluser]Pascal Kriete[/eluser]
What data are you storing in your sessions? I usually just have the user_id in there, with the occasional flash-data or form token. Most of the other user settings are in some way persistent, so I drop them in a userdata table.

Just curious, really.

[eluser]Randy Casburn[/eluser]

So I don’t really know where I am going with this

Neither do we from the comments so far...have you come up with any concrete questions other than these two...

Why in the world isn’t the default set to use sessions with only a single session handle given to the user?

Why are there DB specific functions like “mysql_fetch_assoc” in the recommended session lib “KNDB_Session”?

Q1: I guess I'm a fool, because I don't understand this question.

Q2: That is from a Wiki page...you know...created and edited by anyone. That page, and subsequently that recommendation was made by George Petsagourakis. I don't know George, but I suppose George uses MySQL so George recommended MySQL. That certainly doesn't make it a recommendation sanctioned and supported my CodeIgniter or EllisLabs.

I can tell you that CI is flexible enough to let you do just about anything you want to with sessions.

If your issue revolves around security, there just isn't any in any situation. So set up your "willing to accept" parameters first before talking about security.

Looking forward to more concrete questions.

Randy

[eluser]Xeoncross[/eluser]
[quote author="Randy Casburn" date="1217127867"]

So I don’t really know where I am going with this

Neither do we from the comments so far...[/quote]

Wow, my first question - and here I am 44 comments later having a little better understanding of the system.

Well, Storing sessions in a DB is the expected standard in the web world. It not only is the only secure method - but it scales too as you are not tied to the file system.

If the session data is storied in a cookie - then why in the world even use sessions?
Just stick with cookies and make sure people expect the data to be hacked.

BUT if you plan on using sessions (because they are more secure) then it only makes sense to keep the data on the SERVER where it belongs.

I am still unnerved that Ellislab's reversed the whole purpose of the sessions and made them into a cookie like system. I guess no-one's perfect.

Anyway, I am using the DB2_Session class as it is very close to the default Session class and works well with Redux Auth.

[eluser]Randy Casburn[/eluser]
[quote author="Xeoncross" date="1217132513"]Well, Storing sessions in a DB is the expected standard in the web world. It not only is the only secure method - but it scales too as you are not tied to the file system.
[/quote]
PHP provides a session capability but does not have a database capability. Hence, if you are using PHP but have not database, you have no way to store sessions in a DB. The least common denominator scenario then. CI is clearly designed to be used (read it for yourself) in this same least common denominator configuration (WITHOUT a database). It makes perfectly good sense then that it's default configuration would be this way.

Now the documentation tells you how to enable DB stored sessions in the first line. Hence they must realize the importance of this. They also mention in the warning box about "flexibility for the developer". They know they cannot please everyone in this regard maybe...but I don't know.


[quote author="Xeoncross" date="1217132513"]If the session data is storied in a cookie - then why in the world even use sessions?[/quote]

Read the documentation for the answer here.

[quote author="Xeoncross" date="1217132513"]
BUT if you plan on using sessions (because they are more secure) then it only makes sense to keep the data on the SERVER where it belongs.[/quote]

If you said "because the SERVER is more secure, and that's where the session data belongs, I would agree with the statement. As written, there is nothing inherently secure about sessions just because they are sessions.

[quote author="Xeoncross" date="1217132513"]I am still unnerved that Ellislab's reversed the whole purpose of the sessions and made them into a cookie like system. I guess no-one's perfect.[/quote]

Perhaps you just haven't realized yet that CI was designed to work with a minimal platform based upon a least common denominator that assumes that platform would not have a database to work with.

[quote author="Xeoncross" date="1217132513"]Anyway, I am using the DB2_Session class as it is very close to the default Session class and works well with Redux Auth.[/quote]

And like all the rest of us, you've solved the problem in a way that makes sense to you.

Sounds great!

By the way, if you're not running over an SSL link for every session including the fetch of the login page, then most of your concerns (rant) above are really point less.

Randy

[eluser]Xeoncross[/eluser]
[quote author="Randy Casburn" date="1217134597"]CI is clearly designed to be used (read it for yourself) in this same least common denominator configuration (WITHOUT a database). It makes perfectly good sense then that it's default configuration would be this way.[/quote]

No. PHP's default like I said is to store data on the SERVER. I wouldn't mind if it defaulted to files - I'd expect that but...

1) This is a developers framework - not a noob's CMS i.e. they should opt for security over someone not having a DB (even free hosts have DB's).

2) EVEN IF NO ONE HAD DB's - Why would they change the PHP default of partly secure file system storage to COOKIE like insecurity? It has nothing to do with lowest denominator - it is just a bad choice.


[quote author="Randy Casburn" date="1217134597"]
By the way, if you're not running over an SSL link for every session including the fetch of the login page, then most of your concerns (rant) above are really point less.
[/quote]

When it comes to security, it is only how valuable the resource is. Millions of people have blogs and sites on NON-SSL lines and they never have a problem. Why? because it is not worth the trouble:reward. But if data was stored in a Cookie on the user's computer then it would be easier, and the ratio of trouble:value would be worth it. Like wise, if a financial site was on a NON-SSL line then it also would be worth the trouble:reward.

[eluser]Randy Casburn[/eluser]
I'm with you on all this Xeon and agree partially with what you are saying. Many folks can't comprehend how a man-in-the-middle attack can even happen. Hijacking sessions based on this exposed cookie is a real threat...I hear you.

Financial applications aren't always the reward. Sometimes folks just want to be a pain in the arse.

Over the years I've seen these topics go on and on and on about how NOT secure cookies, sessions, and you name it are by one expert with the best solution and the next and the next and the next and the next...

Then, you ask to get invited to their site...just to find out that not only are you sending user names and passwords together in the clear (over an unencrypted link), but they've got the DOM storing them as plain as day too.

The next web app you pull up, fire up your firebug, open up the DOM and check out your password and user name sitting there plain as day. Then, log out and in about 40% of the situations I find, after you log out, you can still find your user name and password sitting in the DOM...in clear text.

Right, don't put session data in your cookies, put your sessions on your server...but there is a whole lot more to do my friend.

Take all that knowledge you seem to have and spread it around.

You've already solved the your session problem.

Randy

[eluser]Xeoncross[/eluser]
[quote author="Randy Casburn" date="1217138010"]Sometimes folks just want to be a pain in the arse.[/quote]
ya that too. :-S

[quote author="Randy Casburn" date="1217138010"]
The next web app you pull up, fire up your firebug, open up the DOM and check out your password and user name sitting there plain as day. Then, log out and in about 40% of the situations I find, after you log out, you can still find your user name and password sitting in the DOM...in clear text.
[/quote]

Your right, I haven't been checking the sites lately - I'll make sure to start doing this again. After all, even the large site "magnolia" stored their passwords in plain text - and they were stolen right from the system!