Segurança da Session

>
Loguei com um usuário com poucas permissões, sabendo o nome da session eu criei no PHP uma session com o mesmo nome e dei o valor "ADM" (que na verdade n é ADM mas usamos no exemplo)

Como assim? Criou no PHP uma session com o mesmo nome?

Você criou um script php pra criar a session? Os usuários não terão acesso a isso... eles não podem mudar os valores da session.

>
O que acontece é... essa simples invasão por session é realmente simples?

Sim, é realmente simples. Existem outros tipos de ataque, as sessões são armazenadas em disco e isso facilita a recuperação e manipulação desses dados.

>
O que faço para defender?

Criptografe a sessão se você estiver armazenando dados sensíveis.

>
Os usuários não terão acesso a isso... eles não podem mudar os valores da session.

Os usuários não, mas em hospedagens compartilhadas, dependendo das configurações do servidor, a sessão é facilmente manipulada por outras aplicações maliciosas

>
Os usuários não, mas em hospedagens compartilhadas, dependendo das configurações do servidor, a sessão é facilmente manipulada por outras aplicações maliciosas

Puuuullltz...

Verdade joão...

Mas agora me veio uma dúvida: Se eles tem acesso à sessão, tem acesso aos scripts também certo? Logo, eles tem acesso ao algoritmo de criptografia.

É isso mesmo?

>
É isso mesmo?

Não,

As aplicações, em hospedagens compartilhadas, são isoladas do restante do servidor (pelo menos deveria ser assim), como se fosse um sandbox. Se uma aplicação tentar acessar alguma coisa fora dessa sandbox, ela não vai conseguir.

O problema é que, apesar do root da aplicação impedir que ela acesse o código de outra aplicação em outro root, o diretório temporário, de upload e onde as sessões são armazenadas pode ser comum.

Se esses diretórios forem comuns para todas as aplicações na hospedagem compartilhada, então uma aplicação terceira conseguirá ter acesso aos dados de sessão e arquivos temporários de outra aplicação.

Mas isso só acontece em servidores com problemas de configuração, em um ambiente bem configurado isso não pode ocorrer.

Obrigado João, exatamente minhas duvidas foram tiradas aqui.

Até mais.

Não que eu esteja assim muito interessado ness assunto hoje, mas e com quais argumentos deveríamos chegar no Suporte do Servidor (ou alguém acima) para questionar sobre tais configurações?

Tipo, o que deveria ser perguntado e com quais valores compararíamos?

Encontrei Algo interessante

A lógica é bem simples:

1. Configurar o tempo de sessão para 1 hora (Padrão do php: 3 horas);

2. Configurar os cookies de sessão para não serem acessados via JS (Ataques XSS);

1. Configurar o php para não recuperar sessões via URL (Exemplo acima);

PHP
<?php
// Iniciamos a sessão.

ini_set('session.cache_expire', 60);
ini_set('session.cookie_httponly', true);
ini_set('session.use_only_cookie', true);

session_start();
?>

www.revistaphp.com.br

Caso o servidor não aceite ini_set a nossa proteção irá falhar. Então fazemos outra em conjunto com esta. Ela verifica se foi digitada uma id de sessão na URL. Se tiver, nós destruímos a sessão, geramos outra id para a seção e iniciamos ela.

PHP

<?php
if(strpos(strtolower($_SERVER['REQUEST_URI']), 'phpsessid') !== false)

{

session_destroy();
session_regenerate_id();
session_start();
}
?>

www.revistaphp.com.br

Ficando assim nosso script final:

PHP

<?php
// Iniciamos a sessão.

ini_set('session.cache_expire', 60);
ini_set('session.cookie_httponly', true);
ini_set('session.use_only_cookie', true);

session_start();

// Se for tentado alguma SID, destruímos a sessão e geramos outra.
if(strpos(strtolower($_SERVER['REQUEST_URI']), 'phpsessid') !== false)
{

session_destroy();
session_start();
session_regenerate_id();
}
?>

www.revistaphp.com.br

Bom, é isso. Basta colocar essa validação no topo das páginas do seu site que já estará bem mais seguro. Não se baseiem somente isso também... Procurem outros métodos contra invasão ok?

Abraços e até a próxima!

Retirado de:

http://www.revistaphp.com.br/artigo.php?id=185

usei essa defesa de cima e continua funcionando deletar a sessão no config, criar uma em um notepad e dar o valor adm

ja pensou em deletar o PHPSESSID?

unset...