1.11M Members

CodeIgniter Session class unserialize() failure

 
0
 

Receiving this CodeIgniter message in my error log every so often (and by every so often I mean quite often):

ERROR - 2013-07-21 07:26:40 --> Severity: Notice  --> unserialize() [<a href='function.unserialize'>function.unserialize</a>]: Error at offset 124 of 187 bytes /home/daniweb/httpdocs/system/libraries/Session.php 724

Could a problem unserializing() be caused by a session cookie size that is too big (and therefore the serialized version wasn't fully writen)? I encrypt session cookies.

My session cookie is fine by a long shot, but I'm wondering if this could be an issue for others??

 
0
 

Haven't noticed anything - how does it manifest itself? Failed post?

 
0
 

I don't know how it manifests itself. It's only happening for a small percentage of users, as I'm finding in the error log. If I had to guess, they're having a problem trying to log in.

 
0
 

I was able to log the input for the error cases and, in all case, they are recent timestamps. There are only two places in CodeIgniter's Session class where the _unserialize() class method gets called, and I can't understand how a timestamp would end up in either of those places?

 
0
 

I did a search through my entire project and here's all of the instances in my code that deals with the Session class:

$this->session->set_userdata(array('userid' => $userid, 'password' => $password));
$this->session->unset_userdata(array('userid' => '', 'password' => '', 'oauth_userid' => '', 'oauth_password' => ''));
$this->session->set_userdata(array('userid' => $me['userid'], 'password' => md5($this->input->post('password'))));
$this->session->set_userdata(array('oauth_userid' => $memberinfo['userid'], 'oauth_password' => $cookied_password));
$this->session->set_userdata(array('userid' => $memberinfo['userid'], 'password' => md5($this->input->post('password'))));
$this->session->set_userdata(array('userid' => $userid, 'password' => md5($password)));
$this->session->set_userdata('password', md5($properties['password']));

And then, of course, within /system/libraries/Session.php a bunch of times. As you can see, no where in my code am I doing anything with a timestamp. Perhaps the timestamp is coming from the last activity timestamp??? But how/why?!

 
0
 

LOL I'm so stupid :)

I'm writing to my error log the timestamp of the error followed by the input for the error case. Apparently the error case is just an empty string, and it's just logging the timestamp of the error, and silly me thought that was the input itself!!

Still don't know what the issue is though LOL.

 
0
 

Could a problem unserializing() be caused by a session cookie size that is too big (and therefore the serialized version wasn't fully writen)?

I think this could still be a valid reason, because in sess_read() there is:

// Decrypt the cookie data
if ($this->sess_encrypt_cookie == TRUE)
{
    $session = $this->CI->encrypt->decode($session);
}
else
{
    // encryption was not used, so we need to check the md5 hash

If you can log the broken $session values, then you can try to run the decode method manually and see if it fails.

 
0
 

When I attempted to log the broken $session values, they were complete gibberish (tons of weird symbols and characters, etc). It looked like binary data.

 
0
 

Dani, did you changed the encryption key lately? I can replicate the issue by trying to decode cookies encoded with a previous key.

By the way:

When I attempted to log the broken $session values, they were complete gibberish (tons of weird symbols and characters, etc). It looked like binary data.

this happens because you still need to pass the data through _unserialize().

 
0
 

I didn't, but one of the things that I changed earlier today was to no longer encrypt session cookies.

this happens because you still need to pass the data through _unserialize()

No, no. I know what serialized data looks like :) This was not serialized data. This looked like a binary string of some sort where every character was a weird symbol.

 
0
 

Consider that this can happen also with unknown keys, could this be an attempt to find your encryption key?

No, no. I know what serialized data looks like :) This was not serialized data. This looked like a binary string of some sort where every character was a weird symbol.

Sorry, I wrote this because while testing I noted something similar to binary code, to get the array I had to use urldecode() and after the _unserialize() of the Session.php file. I will check better tomorrow :)

 
1
 

Consider that this can happen also with unknown keys, could this be an attempt to find your encryption key?

Who knows :) I've decided to give up and permanently switch to using unencrypted session cookies, which no longer throws any PHP warnings if there is invalid cookie data. There's no super sensitive information in our session cookies anyways, so ultimately no necessity in encryption/decryption overhead.

 
0
 

OK, new issue. Ever since switching from encrypted session cookies to unencrypted ones (in config.php), I went from getting those unserialize error messages to instead getting this error message:

ERROR - 2013-08-29 00:50:48 --> Severity: Notice  --> iconv() [<a href='function.iconv'>function.iconv</a>]: Detected an illegal character in input string /home/daniweb/httpdocs/system/core/Utf8.php 89
 
0
 

Now I'm getting multiple iconv() errors:

ERROR - 2013-08-29 12:45:11 --> Severity: Notice  --> iconv() [<a href='function.iconv'>function.iconv</a>]: Detected an illegal character in input string /home/daniweb/httpdocs/system/core/Utf8.php 89
ERROR - 2013-08-29 12:45:11 --> Severity: Notice  --> iconv() [<a href='function.iconv'>function.iconv</a>]: Detected an illegal character in input string /home/daniweb/httpdocs/system/core/Utf8.php 89
ERROR - 2013-08-29 12:51:05 --> Severity: Notice  --> iconv() [<a href='function.iconv'>function.iconv</a>]: Detected an incomplete multibyte character in input string /home/daniweb/httpdocs/system/core/Utf8.php 89

After cereal pointed me towards a vulnerability in having the encrypted password in the unencrypted cookie, I decided it was easier to go back to using a totally encrypted cookie as opposed to just making a stronger-encrypted password. There are some other vulnerabilities that I don't want to open myself up to by allowing people to see what information gets transmitted within the cookie and how logins are handled.

And the iconv() issue seemed to just be swapping out one issue for another.

Isn't it about time forums rewarded their contributors?

Earn rewards points for helping others. Gain kudos. Cash out. Get better answers yourself.

It's as simple as contributing editorial or replying to discussions labeled or OP Kudos

You
This article has been dead for over six months: Start a new discussion instead
Post:
Start New Discussion
View similar articles that have also been tagged: