Série de palestras ASP (vinte) Mantendo a segurança de aplicativos ASP
Autor：Eve Cole
Data da Última Atualização：2009-05-30 19:58:35
Nunca subestime a importância de definir corretamente as configurações de segurança. A configuração inadequada das configurações de segurança não apenas expõe seus aplicativos ASP a adulterações desnecessárias, mas também impede que usuários legítimos acessem seus arquivos .asp.
Os servidores Web fornecem vários métodos para proteger seus aplicativos ASP contra acesso não autorizado e adulteração. Depois de ler as informações de segurança neste tópico, reserve um momento para revisar cuidadosamente a documentação de segurança do Windows NT e do servidor Web.
Permissões NTFS Você pode proteger arquivos de aplicativos ASP aplicando permissões de acesso NTFS a arquivos e diretórios individuais. As permissões NTFS são a base da segurança do servidor Web, definindo diferentes níveis de acesso a arquivos e diretórios para um usuário ou grupo de usuários. Quando um usuário com uma conta válida do Windows NT tenta acessar um arquivo com permissões restritas, o computador verifica a lista de controle de acesso (ACL) do arquivo. Esta tabela define as permissões concedidas a diferentes usuários e grupos de usuários. Se a conta do usuário tiver permissão para abrir o arquivo, o computador permitirá que o usuário acesse o arquivo. Por exemplo, o proprietário de um aplicativo Web em um servidor Web precisa de permissões de alteração para exibir, alterar e excluir os arquivos .asp do aplicativo. No entanto, os usuários públicos que acessam o aplicativo devem receber apenas permissões somente leitura, limitando-os a visualizar, mas não a alterar as páginas da Web do aplicativo.
Mantendo a segurança do Global.asa Para proteger totalmente seu aplicativo ASP, certifique-se de definir permissões de arquivo NTFS no arquivo Global.asa do aplicativo para o usuário ou grupo apropriado. Se Global.asa contiver comandos que retornam informações ao navegador e você não proteger o arquivo Global.asa, as informações serão retornadas ao navegador mesmo que outros arquivos no aplicativo estejam protegidos.
NOTA Certifique-se de aplicar permissões NTFS uniformes aos arquivos do aplicativo. Por exemplo, se você acidentalmente restringir demais as permissões NTFS para um arquivo que um aplicativo precisa conter, os usuários poderão não conseguir visualizar ou executar o aplicativo. Para evitar tais problemas, planeje cuidadosamente antes de atribuir permissões NTFS aos seus aplicativos.
Permissões do servidor Web Você pode restringir o modo como todos os usuários podem visualizar, executar e manipular suas páginas ASP configurando permissões no seu servidor Web. Ao contrário das permissões NTFS, que fornecem uma maneira de controlar o acesso de usuários específicos a arquivos e diretórios de aplicativos, as permissões do servidor Web se aplicam a todos os usuários e não diferenciam os tipos de contas de usuário.
Para os usuários que executarão seus aplicativos ASP, você deverá seguir estas diretrizes ao definir permissões do servidor Web:
Permita permissões de leitura ou script no diretório virtual que contém o arquivo .asp.
Permita permissões de "leitura" e "script" nos diretórios virtuais onde os arquivos .asp e outros arquivos contendo scripts (como arquivos .htm, etc.) estão localizados.
Permita permissões de leitura e execução em diretórios virtuais que contenham arquivos .asp e outros arquivos que exijam permissões de execução para serem executados (como arquivos .exe e .dll, etc.).
Arquivos de mapeamento de script O mapeamento de script do aplicativo garante que o servidor Web não baixe acidentalmente o código-fonte do arquivo .asp. Por exemplo, mesmo se você definir permissões de leitura para o diretório que contém um arquivo .asp, o servidor Web não retornará o código-fonte do arquivo, desde que o arquivo .asp pertença a um aplicativo de mapeamento de script para os usuários.
Segurança de cookies
ASP usa o cookie SessionID para rastrear informações específicas do navegador da Web durante uma visita ou sessão do aplicativo. Isto significa que as solicitações HTTP com cookies correspondentes são consideradas provenientes do mesmo navegador da Web. Os servidores Web podem usar cookies SessionID para configurar aplicativos ASP com informações de sessão específicas do usuário. Por exemplo, se seu aplicativo for uma loja de música on-line que permite aos usuários selecionar e comprar CDs, você poderá usar o SessionID para rastrear as seleções do usuário enquanto elas percorrem o aplicativo.
O SessionID pode ser adivinhado por hackers?
Para evitar que hackers de computador adivinhem o cookie SessionID e obtenham acesso às variáveis de sessão de um usuário legítimo, o servidor Web atribui um número gerado aleatoriamente a cada SessionID. Sempre que o navegador da Web do usuário retorna um cookie SessionID, o servidor recupera o SessionID e o número atribuído e, em seguida, verifica se ele corresponde ao número gerado armazenado no servidor. Se os dois números corresponderem, o usuário terá permissão para acessar a variável de sessão. A eficácia desta técnica reside no comprimento do número atribuído (64 bits), o que torna quase zero a possibilidade de um hacker adivinhar o SessionID e roubar a sessão ativa do usuário.
Criptografar cookie SessionID importante
Um hacker de computador que intercepte o cookie sessionID de um usuário pode usar esse cookie para se passar pelo usuário. Se um aplicativo ASP contiver informações privadas, números de cartão de crédito ou de contas bancárias, um hacker de computador com um cookie roubado poderá iniciar uma sessão ativa no aplicativo e obter essas informações. Você pode evitar que o cookie SessionID seja interceptado criptografando o link de comunicação entre o seu servidor Web e o navegador do usuário.
Protegendo conteúdo ASP restrito usando mecanismos de autenticação Você pode exigir que cada usuário que tente acessar conteúdo ASP restrito tenha um nome de usuário e senha de conta válidos do Windows NT. Sempre que um usuário tenta acessar conteúdo restrito, o servidor Web executa a autenticação ou verificação da identidade do usuário para verificar se o usuário possui uma conta válida do Windows NT.
O servidor web suporta os seguintes métodos de autenticação:
Autenticação Básica Solicita ao usuário um nome de usuário e senha.
A autenticação de solicitação/resposta do Windows NT obtém criptografadamente informações de identidade do usuário do navegador da Web do usuário.
Entretanto, o servidor Web somente autentica o usuário se o acesso anônimo for proibido ou restrito pelas permissões do sistema de arquivos do Windows NT.
Proteger os scripts ASP da Metabase que acessam a metabase requer direitos de administrador no computador onde o servidor Web está sendo executado. Ao executar esses scripts em um computador remoto, você deve conectar-se por meio de uma conexão autenticada, como usar a autenticação de solicitação/resposta do Windows NT. Você deve criar um servidor ou diretório para o arquivo .asp administrativo e definir seu método de autenticação de segurança de diretório para autenticação de solicitação/resposta do Windows NT. Atualmente, a autenticação de solicitação/resposta do Windows NT só é suportada pelo Microsoft Internet Explorer versão 2.0 ou posterior.
Mantenha a segurança do aplicativo usando SSL
Como um recurso de segurança do servidor Web, o protocolo Secure Sockets Layer (SSL) 3.0 fornece uma maneira virtual segura e transparente de estabelecer conexões de comunicação criptografadas com os usuários. O SSL garante a autenticação do conteúdo da Web e pode confirmar com segurança a identidade dos usuários que acessam sites restritos.
Com o SSL, você pode exigir que os usuários que tentam acessar aplicativos ASP restritos estabeleçam uma conexão criptografada com o seu servidor, evitando que informações importantes trocadas entre usuários e aplicativos sejam interceptadas.
Mantendo a segurança dos arquivos incluídos Se você incluir arquivos localizados em um diretório habilitado para SSL a partir de um arquivo .asp localizado em um diretório raiz virtual desprotegido, o SSL não será aplicado aos arquivos incluídos. Portanto, para garantir que o SSL seja aplicado, certifique-se de que os arquivos incluídos e incluídos estejam em um diretório habilitado para SSL.
Autenticação de cliente Uma maneira muito segura de controlar o acesso ao seu aplicativo ASP é exigir que os usuários efetuem login com autenticação de cliente. Uma credencial de cliente é um cartão de identificação digital que contém as informações de identidade do usuário e funciona da mesma forma que uma forma tradicional de identificação, como passaporte ou carteira de motorista. Os usuários geralmente obtêm qualificações de clientes de uma organização terceirizada confiável, que confirma as informações de identidade do usuário antes de emitir certificados de qualificação. (Normalmente, essas organizações pedem um nome, endereço, número de telefone e nome da organização; o nível de detalhe nesta informação varia dependendo do nível de status atribuído.)
Sempre que um usuário tenta fazer login em um aplicativo que requer verificação de elegibilidade, o navegador da Web do usuário envia automaticamente as credenciais do usuário ao servidor. Se o recurso de mapeamento de qualificação SSL (Secure Sockets Layer) do servidor Web estiver configurado corretamente, o servidor poderá verificar a identidade de um usuário antes de conceder acesso a um aplicativo ASP.
Scripts ASP para lidar com certificação de qualificação Como desenvolvedor de aplicativos ASP, você pode escrever scripts para verificar se existe uma qualificação e ler os campos de qualificação. Por exemplo, você pode acessar o campo de nome de usuário e o campo de nome da empresa na qualificação. O Active Server Pages armazena informações de qualificação na coleção ClientCertificate do objeto Request.
O servidor Web deve ser configurado para aceitar ou exigir qualificações do cliente antes de poder ser processado através do ASP; caso contrário, a coleção ClientCertificate estará vazia.
