Protegendo funções
Gerenciamento de função permite a você gerenciar a autorização para seu aplicativo com categorias que você cria, conhecido como "funções". Atribuindo usuários a funções, você pode controlar o acesso a partes diferentes do seu aplicativo Web com base em uma função em vez de, ou além de, um nome de usuário.Por exemplo, um aplicativo do funcionário pode ter funções como gerentes, funcionários, diretores e assim por diante, onde diferentes privilégios forem especificados para cada função.
Os usuários podem pertencer a mais de uma função.Por exemplo, se o seu site for um fórum de discussão, alguns usuários poderão estar nas funções de membro e moderador, ao mesmo tempo.Você pode definir cada função para ter privilégios diferentes no site, e um usuário que está em ambas as funções, em seguida, teria dois conjuntos de privilégios.
Enquanto as melhores práticas de codificação e configuração podem melhorar a segurança de seu aplicativo, também é importante que você continue protegendo seu aplicativo, atualizando através da última correção de segurança do Microsoft Windows e Internet Information Services (IIS), bem como qualquer correção do Microsoft SQL Server, Active Directory ou outras fontes de dados de funções.
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).
Proteger configuração de gerenciador de função
O recurso de gerenciamento de função está desativado por padrão para aplicativos ASP.NET para melhorar a segurança dos aplicativos que não usem o Gerenciador de funções.Quando o recurso de gerenciamento de função está ativado, as definições de configuração padrão são definidas para os valores mais seguros.Para obter informações sobre configurações de gerenciamento de função e seus valores padrão, consulte roleManager elemento (esquema configurações ASP.NET).
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ê proteja nomes de função armazenadas em cache em um cookie por configuração do atributo cookieProtection do elemento roleManager para All.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, você deve definir 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.
Servidores hospedeiros também podem restringir a capacidade de substituir definições de configuração a partir da configuração da máquina negando direitos de substituição.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 função
Sequências de conexão
Como mencionado anteriormente, é importante proteger a sequência de conexão que é usada para acessar SQL Server, Active Directory ou outro aplicativo de fonte de dados.Para manter a conexão ao seu servidor de banco de dados seguro, você deve criptografar informações de sequência de conexão na configuração usando a 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
Para conectar-se a computadores executando SQL Server, você deve usar 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 gerenciamento de função reverte para a identidade do processo.Você deve certificar-se que a identidade do processo que está executando o ASP.NET (por exemplo, o pool de aplicativos) é a conta do 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 funções 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 privilégios mínimos para o ID de usuário que é usado para conectar ao banco de dados de função do 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 que permite ao SQL Server 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 de 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 o armazenamento de autorização
Para melhorar a segurança de seu fonte de dados ao usar o AuthorizationStoreRoleProvider, você deve armazenar as informações de função em um servidor Active Directory, em oposição a um armazenamento de autorização baseado em arquivo.Isso pode evitar o arquivo de armazenamento de diretiva de ser exposto caso o servidor Web seja comprometido.
O recurso de gerenciamento de função reverte para a identidade do processo ao se conectar a um servidor Active Directory.Você deve certificar-se que a identidade do processo que está executando o ASP.NET (por exemplo, o pool de aplicativos) é a conta do processo padrão ou uma conta de usuário restrito.Para obter mais informações, consulte ASP.NET Impersonation.Além disso, você deve atribuir permissões para a conta no armazenamento de autorização Active Directory que permite o acesso a somente o aplicativo específico do Gerenciador de autorização ou escopo exigido pelo seu aplicativo ASP.NET.
Você deve usar uma ferramenta de criptografia de rede, como Segurança do Protocolo de Internet (IPSec) para proteger a conexão com o servidor Active Directory.
Proteger o cookie de função
Você pode especificar a ser armazenado em cache nomes da função de um usuário em um cookie de sessão para melhorar o desempenho, definindo o cacheRolesInCookie atributo das roleManager elemento de true. Por padrão, os nomes de funções são armazenados em um formato criptografado, mas você deve fornecer segurança adicional para o cookie de funções definindo o atributo cookieRequireSSL para true e somente armazenar em cache funções em um cookie de sessão quando o SSL está ativado.Isso evita o cookie de função de ser exposto através da rede e de ser usado em um ataque de repetição contra seu aplicativo.
Evitando a compartilhação de cookies entre aplicativos
Se o atributo cacheRolesInCookie do elemento roleManager é definido como true, e se o atributo cookiePath estiver definido para um caminho que inclui vários aplicativos, o mesma função cookie será enviado para vários aplicativos.Você pode compartilhar o cookie de função em vários aplicativos, especificando as mesmas informações de criptografia no elemento de configuração machineKey para cada aplicativo.
Para evitar compartilhamento do cookie de nomes de função para vários aplicativos, especifique chaves de criptografia separada no elemento de configuração machineKey para cada aplicativo, defina o atributo cookiePath para cada aplicativo para o caminho de aplicativos específicos e defina a propriedade ApplicationName para um valor exclusivo para cada aplicativo.
Protegendo páginas da Web que usam funções
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 o uso de Secure Sockets Layer (SSL) e exigem que os usuários tenham efetuado logon para executar operações confidenciais como atualização de informações do usuário ou exclusão de 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 podem reduzir a resposta da fonte de dados da funçã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 fazem uso de 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 de associação de funções 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 seu 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.
Trace Information (Informações de Rastreamento)
O servidor Web pode ser configurado para rastreamento quando certas ações ocorrem sobre o recurso de gerenciamento de função e armazenam as informações de rastreamento em um arquivo de log.Porque informações sigilosas como nomes de função e nomes de usuário podem ser armazenados no arquivo de log de rastreamento, você deve restringir o acesso para a capacidade de ativar o rastreamento para os Administradores apenas, bem como a capacidade de configurar o local do arquivo de log de rastreamento e o acesso ao arquivo de log de rastreamento.
Provedores de função personalizada
Quando criar um provedor de funçã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 funçã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 função SQL Server ou um provedor de função personalizada, sua fonte de dados pode estar configurado para armazenar dados de função em um formato culture-sensitive.No entanto, o ASP.NET sempre avalia nomes de função especificados no elemento de configuração autorização e nomes de função na fonte de dados como cultura invariável.Como resultado, usuários não autorizados podem obter permissões indesejadas porque quando seu nome de função não autorizado é tratado como cultura invariável, é o mesmo que o nome de uma função autorizado.Para evitar que os usuários obtenham acesso não autorizado, certifique-se de que nomes de funções são exclusivos quando avaliada como cultura invariável.