Sessões de Codeigniter sendo destruídas no IE 10 ao mudar de página

Isso pode parecer direto, mas não consegui encontrar uma solução para ele. Estou usando a versão mais recente da CI para construir uma estrutura de site. Estou usando sessões para armazenar informações de access para permitir que os usuários acessem determinadas páginas. Isso funciona bem no Firefox, no Chrome, no Safari e nas versões IE 9 e abaixo. No entanto, com o IE10, as sessões estão sendo desativadas automaticamente quando eu mudo páginas dentro da estrutura. Então, por exemplo, estou no painel e eu clico em um link para me levar ao localhost / sitename / admin / settings, o IE10 destrói todas as informações da session e, assim, estou logado e redirecionado para a página de login. Eu tentei mudar sess_cookie_name para cisins (eu vi isso em outras respostas), mas isso não teve efeito.

Alguém mais encontrou esta questão, ou conhece uma solução de trabalho?

Desde já, obrigado.

EDITAR:

Deveria ter esperado para publicar isso 🙂

Solução encontrada depois de mais cavar,

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

Nova pergunta, então, é sess_match_useragent absolutamente importante para fins de segurança da CI, ou pode permanecer para todos os navegadores?

Esta é uma questão difícil de responder de forma objetiva e completa, pois existem muitos fatores em jogo.

A inclusão do agente do usuário como parte da verificação da session é útil porque reduz a probabilidade de seqüestro de session. No entanto, considere isso:

  1. Pode usar sess_match_ip igualar ou exceder a eficácia de sess_match_useragent em uma perspectiva de segurança? Ao combinar o IP, um invasor seria obrigado a usar o mesmo IP legitimamente, ou tentá-lo e compará-lo ao acessar seu servidor. A verificação do agente do usuário pode ser falsificada com muita facilidade, a falsificação de IP é significativamente mais difícil e provavelmente exigirá que a rede do usuário seja comprometida para ser efetiva (por exemplo, outro indivíduo na mesma rede, rede local ou mesmo no mesmo computador).

  2. Você está usando criptografia SSL para transmitir dados de forma segura? Caso contrário, é concebível que um ataque de intermediário tornaria sua aplicação explorável, independentemente da verificação do agente do usuário? Uma vez que o cliente se comunicará com o servidor sem nenhuma forma de criptografia, todos os pedidos de HTTP podem ser arrancados, manipulados e reproduzidos. Isso é mais difícil se você habilitar a verificação de IP.

  3. Você realmente quer um comportamento diferente do lado do servidor para diferentes navegadores quando se trata de segurança? Embora possa parecer insignificante agora, é inteiramente concebível que esse tipo de problema possa afetar futuras versões de outros navegadores também (ou ser revertido em futuras revisões do IE, para “corrigi-lo”). A engenharia é uma solução que vale a pena?

Com isso em mente, minha opinião pessoal seria deixá-la totalmente para todos os navegadores. O Internet Explorer ainda representa uma parte considerável do mercado de navegadores, e falta de escrever em uma correção por navegador, não parece valer a pena implementar. Isto é particularmente verdadeiro, dado que os benefícios de segurança são relativamente pequenos à luz de exploits mais fundamentais e a disponibilidade de correspondência de IP.