Protegendo a Associação
A associação do ASP.NET fornece a funcionalidade para gerenciar e autenticar usuários e é mais comumente usada com a autenticação de formulários e controles de autenticação, como os controles Login, LoginView,LoginStatus,LoginName,PasswordRecovery e CreateUserWizard.Este tópico descreve como otimizar a segurança do recurso de associação através de práticas ao configurar um site da Web e a codificação com as classes de associação.
Enquanto seguindo essas práticas adequadas pode melhorar a segurança do seu aplicativo, também é importante que você continuamente mantenha o servidor de aplicativos atualizado com os patches de segurança mais recentes para Microsoft Windows e Serviços de Informações da Internet (IIS), assim como quaisquer patches para Microsoft SQL Server ou outras fontes de dados de associação.
Para obter informações mais detalhadas sobre as práticas recomendadas para escrever código seguro e segurança de aplicativos, consulte o livro"Escrevendo código seguro"de Michael Howard e David LeBlanc e orientação fornecida por Microsoft padrões and Practices)https://www.Microsoft.com/Recursos/practices/padrão.mspx).
Protegendo configurações de associação
O recurso de associação é ativado por padrão para aplicativos ASP.NET e não pode ser desativado.As configurações da configuração padrão são definidas para os valores mais seguros.Para obter informações sobre configurações de navegação e seus valores padrão, consulte Elemento membership (Esquema de configurações do ASP.NET).Você deve definir o atributo requiresQuestionAndAnswer para true, especialmente onde enablePasswordReset ou enablePasswordRetrieval for da mesma forma true.
Protegendo Valores de Configuração
Ao armazenar informações confidenciais em um arquivo de configuração para um aplicativo, você deve criptografar os valores confidenciais usando a configuração protegida.Informações que são especialmente confidenciais incluem as chaves de criptografia armazenadas no elemento de configuração machineKey e sequências de conexão a uma fonte de dados armazenada no elemento de configuração connectionStrings.Para obter mais informações, consulte Criptografando informações de configuração usando configuração protegida.
Proteger chaves de criptografia e Hashing
É altamente recomendável que você criptografe senhas de usuário em fonte de dados de associação usando um atributo passwordFormat definido como Hashed ou Encrypted, onde Hashed é o formato mais seguro.Os valores de chave de criptografia para o algoritmo de criptografia especificado são armazenados no elemento de configuração machineKey.Para criptografia forte, especifique uma chave de criptografia que seja um valor gerado aleatoriamente do comprimento apropriado para o algoritmo de criptografia selecionado.
Em um servidor que hospeda vários aplicativos, é recomendável que você defina chaves de criptografia exclusivas para cada aplicativo.Uma alternativa menos segura é definir uma chave de criptografia única e especificar a opção IsolateApps com a chave.
Você pode definir a configuração de máquina em um servidor para negar que aplicativos substituam as configurações.Isso inclui negar a capacidade de chaves de criptografia serem redefinidas no arquivo Web.config para um aplicativo.
Protegendo conexões com uma fonte de dados de associação
Sequências de conexão
Para manter a conexão do seu servidor de banco de dados segura, você deve criptografar as informações da sequência de conexão na configuração usando Protected Configuration (configuração protegida).Para obter mais informações, consulte Criptografando informações de configuração usando configuração protegida.
Conectando-se ao SQL Server usando segurança integrada
Você deve conectar a computadores executando SQL Server usando segurança integrada para evitar a possibilidade da sequência de conexão estar comprometida e identificação de usuário e senha estejam expostos.Quando você especifica uma conexão que usa segurança integrada para conectar-se a um computador que executa o SQL Server, o recurso de associação reverte para a identidade do processo.Você deve certificar-se que a identidade do processo que executa o ASP.NET (por exemplo, o pool de aplicativos) é a conta de processo padrão ou uma conta de usuário restrito.Para obter mais informações, consulte ASP.NET Impersonation.
Permissões de banco de dados SQL Server
O banco de dados do SQL Server que é usado para armazenar as informações do usuário para associação inclui atribuições de banco de dados e modos de exibição que permitem que você restrinja o acesso de usuário a somente os recursos necessários e visibilidade.Você deve atribuir os privilégios necessários mínimos a uma identificação de usuário que se conecta ao banco de dados de associação SQL Server.Para obter mais informações, consulte Funções e Exibições no Banco de Dados do Servidor de Aplicativos para o SQL Server.
Identidade do processo de trabalho do SQL Server Express
SQL Server Express 2005 inclui um novo modo de operação onde ele pode iniciar um processo de trabalho em execução como a identidade do usuário que está se conectando.Essa funcionalidade é chamada de modo "run as user".Embora esse modo de operação seja adequado para desenvolvimento Desktop quando usando o IIS, iniciar processos de trabalho não é apropriado em servidores Web que hospedem vários clientes, ou bases de código de clientes não confiáveis.Servidores de hospedagem compartilhados que contêm aplicativos que não se confiam devem explicitamente desativar a funcionalidade "run as user".This functionality can be turned off by connecting to the SQL Express instance (for example, osql –E –S .\sqlexpress) and issuing the following Transact-SQL command.
EXEC sp_configure 'show advanced option', '1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure 'user instances enabled', 0
GO
RECONFIGURE WITH OVERRIDE
GO
Protegendo páginas da Web que a associação usar
Páginas de aplicativo que trabalham com dados confidenciais, como as páginas de logon, devem ser protegidas usando mecanismos de segurança Web padrões.Eles incluem medidas como usar Secure Sockets Layer (SSL) e exigir que os usuários tenham efetuado logon para executar operações confidenciais como atualização de informações do usuário ou exclusão usuários.
Além disso, páginas não devem expor dados de recurso confidenciais, como senhas e, em alguns casos, nomes de usuários no texto não criptografado.Garantir que páginas que exibam tais informações façam uso do SSL e mantê-las disponíveis somente para usuários autenticados.Além disso, evite armazenar dados confidenciais importantes em cookies ou enviá-los através de conexões inseguras.
Protegendo Contra a Negação do Ataque de Serviço
Métodos que executam atualizações ou operações de pesquisa grandes pode reduzir a resposta da fonte de dados de associação se chamado simultaneamente por um número de clientes.Para reduzir a exposição a um ataque de negação de serviço, restrinja o acesso a páginas ASP.NET que usam métodos que executam atualizações do banco de dados ou pesquisas a usuários administrativos, e exponha somente páginas ASP.NET que fornecem validação e gerenciamento de senhas para uso geral.
Mensagens de Erro e Eventos
Exceções
Para evitar informações confidenciais sendo expostas a fontes indesejadas, configure seu aplicativo para não exibir mensagens de erro detalhadas ou para exibir mensagens de erro detalhadas somente quando o cliente é o próprio servidor Web.Para obter mais informações, consulte customErrors elemento (esquema configurações ASP.NET).
Log de Eventos
Se o servidor está executando o Windows Server 2003, você pode melhorar a segurança do seu aplicativo, assegurando o log de eventos e configurando parâmetros sobre o tamanho, retenção, e assim por diante do log de eventos para impedir uma negação indireta do ataque de serviço contra ele.
Monitoração saudável
Tentativas de logon bem-sucedidas e com falha são registradas usando o recurso monitoração de integridade do ASP.NET .Na configuração padrão, isso significa que tentativas de login falhas registrarão um nome de usuário e informações de diagnóstico no evento log Application.Certifique-se de que o acesso ao log de eventos é restrito a manter essas informações particulares.
Provedores de Associação Personalizados
Quando criar um provedor de associação personalizado, certifique-se que você siga as práticas recomendadas de segurança para evitar ataques, como ataques de injeção SQL ao trabalhar com um banco de dados.Quando fizer uso de um provedor de associação personalizado, certifique-se de que o provedor foi revisado para práticas de segurança recomendadas.
Trabalhando com caracteres Culture-Sensitive
Ao usar o provedor de membership provider SQL Server ou um membership provider personalizado, o fonte de dados pode estar configurado para armazenar dados de participação em um formato culture sensitive.No entanto, o ASP.NET avalia nomes de usuário do elemento de configuração authorization e nomes de usuários do armazenamento de dados de associação como cultura invariável.Como resultado, um usuário não autorizado é capaz de conceder autorização porque quando o nome de usuário é tratado como cultura invariável, é o mesmo do nome de um usuário autorizado.
Para evitar que os usuários obtenham acesso não autorizado, certifique-se de que nomes de usuários são exclusivos quando avaliadas como cultura invariável.Como alternativa, você pode especificar somente nomes de funções para autorização usando o elemento de configuração Authorization e, em seguida, garantir que os nomes de função sejam exclusivos quando avaliados como cultura invariável.Especificar autorização usando nomes de funções é geralmente preferido, pois criar e gerenciar funções podem ser restritas de uma função administrativa.