2

This may sound straight forward, but I couldn't find a solution to it. I am using the latest version of CI to build a website framework. I am using sessions to store access information for allowing users to access certain pages. This works just fine in firefox, chrome, safari and versions IE 9 and below. However, with IE10, the sessions are being unset automatically when I change pages within the framework. So for instance I'm on a dashboard and I click a link to take me to localhost/sitename/admin/settings, IE10 destroys all session information and thus I am getting logged out and redirected to the login page. I tried changing sess_cookie_name to cisessions (I've seen this in other answers) but that had no effect.

Has anyone else come across this issue, or know of a working solution?

Thanks in advance.

EDIT:

Should have waited to post this :)

Found solution after more digging,

$config['sess_cookie_name']  = 'cisession';
$config['sess_match_useragent'] = FALSE;

New question then, is sess_match_useragent absolutely important for CI security purposes, or can it remain off for all browsers?

klye_g
  • 1,242
  • 6
  • 31
  • 54
  • Did you check IE10 default settings for cookies? Does this happens only on CI or for other sites as well? Using the database as session handler to avoid this could be a good "hack" (and is generally more secure than cookies, even if those encrypted) – Damien Pirsy Jan 25 '13 at 19:27
  • what setting would I be looking for specifically? – klye_g Jan 25 '13 at 19:33
  • $config['sess_use_database'] = TRUE; And then you just work with session as you're used (no query involved, I mean), CI will automatically run the needed queries by itself – Damien Pirsy Jan 25 '13 at 19:35
  • That setting is set as TRUE already – klye_g Jan 25 '13 at 19:36
  • @K_G go to [here](http://whatsmyuseragent.com/) with IE10 and refresh the page a few times and see if your useragent is changing. If it is you may have a plugin of some sort loaded in IE10 that may be causing it. – kittycat Jan 25 '13 at 20:09
  • figured out it was googlechrome frame doing the damage. now to figure out how to remove it from the user agent string in CI – klye_g Jan 25 '13 at 20:17
  • Didn't work for me. IE 10 simply won't set any session variables, even after changing the mentioned settings on CI config. :( – Christian Dechery Sep 08 '14 at 23:48

1 Answers1

0

This is a difficult question to answer objectively and completely as there are many factors at play.

The inclusion of the user agent as part of session verification is useful because it reduces the likelihood of session hijacking. However, consider this:

  1. Can using sess_match_ip match or exceed sess_match_useragent effectiveness from a security perspective? By matching the IP, an attacker would be required to legitimately use the same IP, or try and spoof it when accessing your server. User agent verification can be spoofed very easily, IP spoofing is significantly more difficult and would likely require the user's network to be comprimised to be effective (e.g., another individual on the same network, local network, or even on the same computer).

  2. Are you using SSL encryption to securely transmit data? If not, is it conceivable a middleman attack would render your application exploitable regardless of user agent checking? Since the client will be communicating with the server with no form of encryption, entire HTTP requests can be plucked, manipulated and replayed. This is made more difficult if you enable IP checking.

  3. Do you really want different server-side behaviour for different browsers when dealing with security? While it may seem insignificant now, it is entirely conceivable that this kind of problem may affect future releases of other browsers too (or be reverted in future revisions of IE, to "fix" it). Is engineering a solution worth your time?

With this in mind, my personal opinion would be to leave it off entirely for all browsers. Internet Explorer still represents a sizable share of the browser market, and short of writing in a per-browser fix, it does not seem worth implementing. This is particularly true given the security benefits are relatively small in light of more fundamental exploits and the availability of IP matching.

plasmid87
  • 1,450
  • 1
  • 14
  • 20
  • Replay attacks are trivial with simple IP spoofing. When IP spoofing the attacker would be able to send legitimate requests, but not receive a response back. So if the request is to say delete something the attack would be successful even with IP protection in place. The user's network DOES NOT need to be compromised to spoof an IP. If your IP was `1.2.3.4` and you could make a request like `/delete.php?id=12` I could spoof my IP in my request to `1.2.3.4` and send the same request and it will work. It does not matter that I get a response back as the request is what the server will process. – kittycat Jan 25 '13 at 20:06
  • @crypticツ "and would **likely** require the user's network to be compromised" - I'm not saying it needs to be compromised, but it is **likely** you are on their local network since almost all routers and firewalls implement remote-origin spoofing protection. The question asked whether the user agent checking setting is needed for security, and this illustrates how minor the protection it offers is. – plasmid87 Jan 25 '13 at 20:22