Olá pessoal! Tudo bem ?
Então, como prometido. Hoje o assunto é .NET.
Separei algumas medidas para se manter protegido na linguagem.
Quem desenvolve sabe que sempre devemos configurar o arquivo web.config. Mas o que precisamos mudar nele para manter nosso sistema razoavelmente seguro?
Validate Request
Precisamos sempre validar os dados de entrada da aplicação, portanto colocar sempre o Validate Request com o valor false para evitar um dos ataques mais conhecidos o Cross-site scripting (XSS).
Trace
O trace é um grande aliado para quem desenvolve, porém aquela página grande contendo várias informações sobre a parte interna da aplicação em mãos erradas deve fazer um estrago não? Então, nunca habilite o trace no ambiente de produção.
Debug
Seguindo a linha do trace o debug também, mais um aliado dos desenvolvedores. A configuração padrão para debug é false, então logo que terminar seus testes retorne com o debug para false.
Custom Errors
Que tal personalizar suas páginas de erro? O atributo RemoteOnly é o valor padrão no arquivo web.config, e exibe a página de erro padrão da linguagem. Por isso, use apenas quando estiver rodando sua aplicação local.
Mude para On para o sistema entender que sempre deve exibir páginas de erros customizadas em qualquer ambiente.
Connection Strings
Sabe aquela grande string feita escrita no meio do código para se conectar em um banco de dados? Então esta não é a forma mais apropriada para isso. O melhor a se fazer em uma aplicação .NET é usar o Windows Authentication.
Dessa forma, o arquivo de configuração não haverá nenhum dado de usuário e senha do banco de dados.
Cookies
Configurar o acesso aos cookies somente via HTTP utilizando o HttpOnly, evita que o código do lado do cliente. Ataques xss são comuns por aqui.
View State
Todo mundo que já desenvolveu ou já analisou um código .NET já se deparou com o tal view state, não é mesmo? Por favor! Não coloque dados sigilosos no view state. Estes valores ficam expostos na página através de um input hidden de forma não criptografada.
Nos valores do view state somente são aplicados uma codificação de base 64, ou seja, pode ser facilmente decodificada.
No arquivo web.config tem uma configuração que habilita o modo criptografado do view state que por padrão é desabilitado. Adicione viewStateEncryptionMode="Always" e seja feliz!
Forms Authentication
Cookie Name
Tenha um nome de cookie personalizado. Sempre informe um nome para o cookie de autenticação, ao invés de usar o nome padrão ".ASPXAUTH". Os identificadores globais únicos (GUIDs) são excelentes opções para a segurança do aplicativo, pois são garantidos para serem únicos. O Microsoft Visual Studio inclui uma ferramenta que gerará automaticamente um GUID para você. Você pode encontrar esta ferramenta no menu Ferramentas com o nome do comando "Criar GUID". Copie o GUID gerado no atributo de nome do elemento de formulários no arquivo de configuração.
Cookie Path
Da mesma forma que o nome, sempre informe um caminho válido para o cookie de autenticação, no lugar do valor padrão "/".
Cookie Less
Por padrão, o valor do parâmetro cookieless é UseDeviceProfile. Isso faz com que o token de autenticação somente seja armazenado em cookie para dispositivos que tenham suportes a cookies. Então configure o cookieless para UseCookies, isso forçará a utilização de cookies para o token de autenticação.
Require SSL
O valor padrão para requireSSL é false. Fazer esta configuração irá forçar o uso de SSL para autenticar os usuários.
Sliding Expiration
Sabe aquela história de que o atacante captura o token de autenticação e se mantém autenticado por tempo ilimitado? Pois é, é aqui que você pode mudar essa história!
Configurar o sliding expiration para false fará com que o tempo de expiração da autenticação seja fixo, invalidando o token de autenticação após um período configurado. Caso o mantenha como true o tempo irá se renovar a cada nova requisição em uma sessão autenticada.
Rolou dificuldade para configurar? Acha que configurou errado e deseja comprovar?
Use o Web.config Security Analyzer!!
Para ajudar os desenvolvedores que desejam configurar uma aplicação ASP.NET segura,
Criado pela empresa H-Security Labs, o WCSA, Web.config Security Analyzer, uma ferramenta que analisa o arquivo de configuração com a finalidade de encontrar vulnerabilidades de segurança.
O WCSA faz mais de 30 verificações de segurança e gera um relatório detalhado com a descrição das vulnerabilidades encontradas, sugestão de configuração e referências a respeito do problema.
Gostou? Então fiquem ligados! No próximo post, irei explicar Desenvolvimento seguro em PHP.
Até a próxima o/.
0 comments:
Postar um comentário