Login

06-20-2008, 12:27 PM

[eluser]fredpyo[/eluser]
Hello everyone, I think this is my first post here on the forums, so... hi!

I've been messing around with CI for about 6 months now... And for the last 2 months, I've been working on a porject for a client.

During the development, we discovered that certain pages did not display correctly on some computers, specifically some that were using a Squid proxy. It took me some time to determine what the problem was. But I think I nailed when when I used Firefox's majestic Firebug.

The setcookie header is... HUGE!

The problem was that the page that couldn't load was one that had plently of flashdata session variables. And thanks to Firebug I discovered that the session data was stored... like this:

Server response
-- HEADER --
setcookie: ci_session=ci_session=a:14:{s:10:"session_id";s:32:"fb48635c97fcd2ad37a01f31470cad5e";s:10:"ip_address";s:12:"200.3.249.98";s:10:"user_agent";s:50:"Mozilla/5.0+(X11;+U;+Linux+i686;+es-ES;+rv:1.8.0.9";s:13:"last_activity";i:1213985065;s:24:"
... and that appears repeated N times (N being the amount of flash variables that I want to store on the session... including old and new flashdata).
-- BODY --
<html>
...
</html>

Pasting that into a wordeditor returned a wooping 22KB just for the session variables!!!

I looked deeper into the session handling class and - I might be totally mistaken about this - it seems to call the setcookie php funcion for every variable I want to save, concatenating each time the variables that were stored before with the new variable!

So, like I said, I might be totally wrong about this... but... is this a problem/bug?

I really need to get this session stuff fixed... so I'm about to pull my sleeves and sit down and hack the session and view codes. Something like setting the cookies just once just before the first view is loaded or something like that (I really should that a look at how the views are actually loaded before I make any other bold statements, shouldn't I?).

But, besides that tiny detail, CI is fantastic!
Thanks in advance for the aid.

Federico Cáceres

06-20-2008, 01:31 PM

[eluser]attos[/eluser]
I use database sessions. The cookie only stores the session ID.
Look into the documentation. The wiki also has some information about it.

06-20-2008, 02:32 PM

[eluser]fredpyo[/eluser]
Yes attos, I've thought about database sessions, I was even going to try them this weekend, I need that extra layer of security.

But... still it doesn't change the fact of what's going on up there with the cookies!

06-20-2008, 08:51 PM

[eluser]attos[/eluser]
What is the security layer you need?
Due to the inherent connectionless of the HTTP protocol, you need to maintain some session data or identifier between the server and the client. This can be achieved with cookies, hidden fields on URL encoded.
I see no security issues sending and retrieving a session id with cookies, as long as there is no direct connection from the client to the database.

06-21-2008, 07:14 AM

[eluser]Popcorn[/eluser]
Database sessions are your best bet.

You can view the different 3rd party ones here :

http://codeigniter.com/wiki/Category:Session/

06-21-2008, 07:31 AM

[eluser]Crimp[/eluser]
This topic pops up from time to time.

Like most, I fully understand that leaving important information client site opens it up for tinkering and tampering.

That's the theory.

What I don't know is how easy or hard it is to hack into an encrypted cookie and bake your own.

Would the Ellislabers really leave the back door to CI wide open?

I doubt it.

06-21-2008, 07:36 AM

[eluser]Popcorn[/eluser]
It shouldn't be too too hard to create your own "fake" session because anyone can download CodeIgniter and view how the session is crafted.

06-21-2008, 09:07 AM

[eluser]Crimp[/eluser]
Yeah, I keep hearing that EVERY time. It shouldn't be too hard. Right?

OK.

Code:
$cookie_data = $this->CI->encrypt->encode($cookie_data);

OK.

Code:
/**

     * Encode

     *

     * Encodes the message string using bitwise XOR encoding.

     * The key is combined with a random hash, and then it

     * too gets converted using XOR. The whole thing is then run

     * through mcrypt (if supported) using the randomized key.

     * The end result is a double-encrypted message string

     * that is randomized with each call to this function,

     * even if the supplied message and key are the same.

     *

     * @access    public

     * @param    string    the string to encode

     * @param    string    the key

     * @return    string

     */

    function encode($string, $key = '')

    {

        $key = $this->get_key($key);

        $enc = $this->_xor_encode($string, $key);

        if ($this->_mcrypt_exists === TRUE)

        {

            $enc = $this->mcrypt_encode($enc, $key);

        }

        return base64_encode($enc);        

    }

I just hit the stop watch.

Good luck.

06-21-2008, 12:51 PM

[eluser]Popcorn[/eluser]
Actually, I retract my previous statement. I totally forgot about the encryption key you have to set within the configuration file. Unless the users hack into your website they would have a very minimal chance of creating a fake session cookie.

07-07-2008, 12:08 AM

[eluser]Chillahan[/eluser]
So Federico is saying the default session handling assigns one cookie for each session item - ouch! One would think out would serialize the data. But, when I inspect my cookie, I only see one cookie. Perhaps it uses additional cookies for Flash data only?

I hope it's managing garbage collection and not adding on to the cookie(s) length each time we update an existing session item's value. Can someone confirm?

Personally, I don't mind using cookie-based sessions. I use the CI database feature to at least AUTHENTICATE the session, though (and I do encrypt it). I just wish CI would add similar functionality for "remember me" logins, so that I don't have to use an insecure cookie separately for that using the cookie helper functions. I've been thinking of setting two cookies though, one with a salt value that is randomly assigned to each user's account upon logging in and selecting "remember me" - this way at least someone can't just create a counterfeit cookie and mimic ANY user. Again, this is what the CI native session class does with its cookie(s) when you enable the database option.