Proteção de páginas - ASP.NET
Boa noite,
Gostaria de saber qual a melhor maneira de proteger as páginas web. Hoje uso um código simples como ( If Session("Validacao") "1" Then Response.Redirect("~/login.aspx", True) ) mas não acho que seja o mais seguro para evitar sequestro de sessão. Existe alguma melhor prática para isso atrelando o ID do IIS ou coisa parecida?
Abraços
Vinicius
Vinicius Cezar
Curtidas 0
Respostas
Luiz Maia
15/06/2009
Ola Vinicius,
O que vc esta fazendo não esta errado não, funciona perfeitamente.
Mas segue algumas considerações:
1 - Por exemplo, caso queira que usuario acessem a pasta "Administracao" somente logados, não se esqueça de incluir as seguintes tags no web.config:
<authentication mode="Forms">
<forms name="Administracao" loginUrl="AcessoNegado.aspx" timeout="100"/>
</authentication>
E também:
<location path="Administracao">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>
E no mais, também faço o mesmo que vc em minhas aplicações, é simples, funcional e seguro:
try
{
if (Session["NomUsuario"].ToString() == "")
{
Response.Redirect("/AcessoNegado.aspx");
}
}
catch
{
Response.Redirect("~/AcessoNegado.aspx");
}
Coloco o codigo geralmente no pageLoad da masterpage da area administrativa.
Abraços
Att
Luiz Maia
GOSTEI 0
Luiz Maia
15/06/2009
E ai Vinícius,
Como esta indo?
Aguardo seu retorno.
Abraços
Att
Luiz Maia
GOSTEI 0
Vinicius Cezar
15/06/2009
Caro Luiz,
Agradeço seu post mas preciso de algo mais seguro visto a criticidade de nossa aplicação. Esse eu já utilizo mas preciso de algo que trave mais minha aplicação e previna fortemente sequestro de sessão. Esse método utilizado por nós pode ser burlado como já demonstrado em algumas palestras que participei.
Agradeço seus comentários para esse post.
Abraços
Vinicius
GOSTEI 0
Luiz Maia
15/06/2009
Ola Vinicius,
Sinceramente não vejo necessidade de usar outra coisa a não ser sessão.
De acordo com a propria Microsoft:
"Considerando o algoritmo usado pelo ASP.NET (15 números aleatórios mapeados para caracteres habilitados para URL), a possibilidade de você adivinhar uma identificação válida é próxima de zero. Não há motivo para substituir o gerador de identificação de sessão padrão pelo seu próprio. Em muitas situações, você apenas facilita a vida dos invasores.
O pior do ataque de seqüestro de sessão é que, uma vez que um cookie tenha sido roubado ou adivinhado, não há muito que o ASP.NET possa fazer para detectar o uso fraudulento do cookie. Novamente, o motivo é que o ASP.NET se limita a verificar a validade da identificação e examina o local de origem do cookie.
"
Caso sua aplicação seja extremamente critica na questão de segurança e necessite guardar informações "a 7 chaves", voce pode criar um modulo HTTP que monitora as solicitações de entrada e as respostas enviadas relativas a cookies de identificação de sessão, mas isto é bem complicado de fazer.
O seqüestro de sessão ocorre quando o invasor captura um identificador de autenticação e adquire o controle da sessão de outro usuário. Geralmente, os identificadores de autenticação são armazenados em cookies ou URLs. Se o invasor capturar o identificador de autenticação, ele poderá transmiti–lo ao aplicativo com uma solicitação. O aplicativo associa a solicitação à sessão legítima do usuário, permitindo ao invasor obter acesso a áreas restritas do aplicativo que exigem acesso autenticado. Assim, o invasor assume a identidade e os privilégios do usuário legítimo.
Vulnerabilidades
As vulnerabilidades comuns que tornam suas páginas da Web e seus controles suscetíveis ao seqüestro de sessão incluem:
•
URLs contendo identificadores de sessão desprotegidos.
•
Mistura de cookies de personalização com cookies de autenticação.
•
Cookies de autenticação transmitidos por meio de links não criptografados.
Ataques
Os ataques de seqüestro de sessão incluem:
•
Repetição de cookie. O invasor captura o cookie de autenticação usando um software de monitoramento de rede ou outros meios, por exemplo, explorando a vulnerabilidade XSS.
•
Manipulação de seqüência de caracteres para consulta. Um usuário mal–intencionado altera o identificador de sessão, que é claramente visível na seqüência de caracteres para consulta da URL.
Contramedidas
Você pode empregar as seguintes contramedidas para impedir o seqüestro de sessão:
•
Usar cookies distintos para personalização e autenticação.
•
Transmitir cookies de autenticação apenas por meio de conexões HTTPS.
•
Não transmitir identificadores de sessão que representem usuários autenticados em seqüências de caracteres para consulta.
•
Fazer uma nova autenticação do usuário antes da realização de operações críticas, como substituição de pedidos, transferência de dinheiro, etc.
Outra coisa que também deve ser feita é sempre CRIPTOGRAFAR as informações.
Se quiser saber mais sobre Session HiJack, dê uma olhada neste artigo:
http://technet.microsoft.com/en-us/magazine/2005.01.sessionhijacking.aspx
Também pode tentar fazer alguma coisa usando HASH, tipo:
string password = Console.ReadLine();
SaltedHash sh = SaltedHash.Create(password);
// imagine storing the salt and hash in a database
string salt = sh.Salt;
string hash = sh.Hash;
Console.WriteLine("Salt: ", salt);
Console.WriteLine("Hash: ", hash);
// after looking up salt and hash, verify a password
SaltedHash ver = SaltedHash.Create(salt, hash);
bool isValid = ver.Verify(password); Estes passos deixam sua aplicação mais segura, mas volto a dizer, não vejo neceddidade do uso de tais métodos.Trabalho no Centro de Processamento de Dados de um Banco em BH, e usamos Sessoes do ASPnet para que usuarios logados trafegem em paginas seguras.Ate hj não tivemos problemas. Aguardo em retorno seu, ok ? AbraçosAttLuiz Maia
GOSTEI 0
Luiz Maia
15/06/2009
E ai Vinicius, como esta indo?
Aguardo um retorno...
Abraços
Att
Luiz Maia
GOSTEI 0
Luiz Maia
15/06/2009
Ola Vinicius,
Como não obtvemos retorno quanto ao seu chamado, estamos procedendo com o fechamento do mesmo.
Estamos a sua inteira disposição caso a dúvida persista ou para qualquer outro tipo de dúvida.
Abraços e sucesso.
Att
Luiz Maia
GOSTEI 0
Vinicius Cezar
15/06/2009
Caro Luiz,
Desculpe a demora pois estava de férias. Bem, voltando... Ok tudo certo! Apenas uma dúvida. Como posso proteger minhas páginas para que não possa haver multi-sessão? ou seja, não quero que no mesmo browser a sessão possa ser aberta em várias abas. Tem também algum exemplo de TIMEOUT?
Forte abraço!
Vinicius
GOSTEI 0
Luiz Maia
15/06/2009
Ola Vinicius,
A questao de mater a sessao ao abrir novo browser, é um problema (acho que nao se trata de problema) do proprio browser, que usa cookies para isto.
No firefox isso não é possível, a não ser que você configure vários profiles sendo executados ao mesmo tempo. Quando você abre uma instância do Firefox, ele sempre "reutiliza" os cookies da outra instância que estava sendo executada.
No IE, cada janela aberta pode ter uma sessão diferente, contanto que elas sejam abertas em separado e não através de cliques em páginas ou "Ctrl + N".
Acho que do jeito que você quer não tem jeito não. Essa é uma realidade: o cookie perdurará por várias janelas abertas com Ctrl - T.
O problema é que as pessoas constroem aplicações web assumindo que a ordem das páginas devem ser exatamente aquelas que os arquitetos pensaram. Só que não dá, pois os usuários apertam o botão voltar, guardam no favoritos, criam atalhos...
Opinião externa:
"Não brigem com o uso comum. E não pensem em soluções gambiarrentas para "corrigir" o mundo web. Busquem usar o mínimo de sessão, aprendam redirect-after-post e, em casos de dados sensíveis, aprendam a setar os headers para não cachear e não armazenar páginas (assim, aparece uma página nova mesmo quando o usuário volta). " Quando ao exemplo de TimeOut, ele pode ser setado de duas formas, setando diretamente na Aplicação no IIS, ou via codigo dentro do arquivo de configuração web.config, como abaixo: <!-- SESSION STATE SETTINGS By default ASP.NET uses cookies to identify which requests belong to a particular session. If cookies are not available, a session can be tracked by adding a session identifier to the URL. To disable cookies, set sessionState cookieless="true". --> <sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" /> Espero ter ajudado. Aguardo retorno. Att Luiz Maia
No IE, cada janela aberta pode ter uma sessão diferente, contanto que elas sejam abertas em separado e não através de cliques em páginas ou "Ctrl + N".
Acho que do jeito que você quer não tem jeito não. Essa é uma realidade: o cookie perdurará por várias janelas abertas com Ctrl - T.
O problema é que as pessoas constroem aplicações web assumindo que a ordem das páginas devem ser exatamente aquelas que os arquitetos pensaram. Só que não dá, pois os usuários apertam o botão voltar, guardam no favoritos, criam atalhos...
Opinião externa:
"Não brigem com o uso comum. E não pensem em soluções gambiarrentas para "corrigir" o mundo web. Busquem usar o mínimo de sessão, aprendam redirect-after-post e, em casos de dados sensíveis, aprendam a setar os headers para não cachear e não armazenar páginas (assim, aparece uma página nova mesmo quando o usuário volta). " Quando ao exemplo de TimeOut, ele pode ser setado de duas formas, setando diretamente na Aplicação no IIS, ou via codigo dentro do arquivo de configuração web.config, como abaixo: <!-- SESSION STATE SETTINGS By default ASP.NET uses cookies to identify which requests belong to a particular session. If cookies are not available, a session can be tracked by adding a session identifier to the URL. To disable cookies, set sessionState cookieless="true". --> <sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes" cookieless="false" timeout="20" /> Espero ter ajudado. Aguardo retorno. Att Luiz Maia
GOSTEI 0
Devmedia
15/06/2009
Vinicius,
a resposta do consultor conseguiu resolver suas dúvidas? Podemos encerrar o chamado?
a resposta do consultor conseguiu resolver suas dúvidas? Podemos encerrar o chamado?
GOSTEI 0
Luiz Maia
15/06/2009
Ola Vinicius, como não obtvemos respostas quando ao seu chamado, estamos procedendo com o fechamento do mesmo.
Continuamos a sua disposição para qualquer tipo de dúvida.
Caso sua dúvida persista, pode posta-lá aqui novamente.
Abraços
Att
Luiz Maia
GOSTEI 0