Está usando o estado da session uma maneira insegura de criar logins de usuários e funções no asp.net

Considere a configuração em que uma lista de IDs e senhas é armazenada em um database em um servidor e quando um usuário digita suas credenciais de login, o code-behind verifica o servidor e define valores como Session [“id”] Session [“login “] para determinar se o usuário tem access a determinada página.

Quando um usuário tenta navegar até uma página, a página examina as variables ​​da session e, em seguida, realoca o usuário, se necessário, e ajusta os botões da página de acordo.

Quão segura é essa configuração.

O login integrado e funcionalidade de function do asp.net parece muito rígido, então eu estava tentando explorar outras opções.

A principal falha no uso da Session é que ela poderia abrir seu site para uma vulnerabilidade de Fixação de Sessão . Como a session é estabelecida quando o usuário chega ao seu site, pode ser possível que o ID da session seja descoberto (por exemplo, por um MITM ).

Exemplo de etapas são as seguintes para esta exploração:

  1. O usuário chega no site HTTP, o ASP.NET fornece uma session e envia o cookie da session para o usuário.
  2. O atacante lê o valor do cookie da session.
  3. O usuário vai para o formulário de login (HTTPS), efetua login e seus valores de id e login são armazenados na session.
  4. O atacante define seu cookie de session como o valor interceptado da etapa 2.
  5. O atacante agora tem uma session válida e autenticada, seqüestrando o usuário agora logado.

Só por esse motivo, recomendo usar o login integrado e a funcionalidade de function, pois o cookie de autenticação não é definido até que a session autenticada seja estabelecida. Se você insistir no método da session, recomendo que chame Session.Abandon() para conceder ao usuário uma nova session no login, para que a session não seja igual à session anterior não autenticada.

Por favor, veja também a minha resposta a esta pergunta: https://stackoverflow.com/a/18077422/413180

O estado da session é uma maneira segura de acompanhar os logins do usuário. Assumindo a configuração padrão (em processo, session baseada em cookie), ela será tão segura quanto a Autenticação de Formulários. O nível exato de segurança que você obtém com ele dependerá de como você configura seu estado de session.

  1. Estado de session sem cookies – isso abre algumas brechas de segurança em potencial (por exemplo, o usuário compartilha a URL que contém o ID da session, o usuário faz uma captura de canvas que contém a URL com o ID da session etc.)

  2. Estado da session fora do processo – Se você estiver usando um serviço de estado da session remota (ou um database para armazenar a session), a segurança da Sessão dependerá do bloqueio do access ao serviço de estado da session ou ao BD apropriadamente.

Dito isso, o login integrado e a funcionalidade de function que você obtém com o Forms Auth não são muito difíceis de estender e desenvolver, em vez de rolar algo do zero. Se você precisa de algo personalizado, você também pode escrever seus próprios provedores de associação e function . Isso é útil se você precisa bloquear as rotas com base no nome de usuário ou function, como você pode fazer isso diretamente no web.config.