Ameaças e Contramedidas de Segurança na Web

Ameaças e Contramedidas de Segurança na Web

Microsoft Corporation

Janeiro 2004

Neste Módulo

Este módulo analisa a segurança de aplicações web a partir da perspectiva das ameaças, contramedidas, vulnerabilidades, e ataques. A incorporação de recursos de segurança no design, na implementação, e na implantação de sua aplicação ajuda a compreender o raciocínio dos invasores. Ao pensar como eles e estar consciente de suas possíveis táticas, você poderá aplicar as contramedidas de forma mais eficaz. Este módulo descreve a metodologia do invasor clássico e traça um perfil da anatomia de um ataque típico.

Este módulo começa com a apresentação das metodologias mais comuns usadas pelos invasores para comprometer aplicações web, e sugere o método STRIDE para categorizar estas ameaças. Ele então apresenta a você as principais ameaças que têm o potencial de comprometimento da rede, da infra-estrutura host e das aplicações. O conhecimento destas ameaças, em conjunto com as devidas contramedidas, fornece as informações essenciais para o processo de elaboração de um modelo de ameaça.

Este módulo permite a você identificar as ameaças que são especificas para o seu cenário em particular, e a priorizá-las com base no grau de risco oferecido ao seu sistema.

Objetivos

Use este módulo para:

• Começar a pensar como um invasor.

• Conhecer o método STRIDE comumente usado para categorizar as ameaças.

• Identificar e conter ameaças no nível da aplicação, do host e da rede.

Aplica-se a:

Aplicações Web

Como Usar Este Módulo

Este módulo identifica um conjunto de ameaças comuns no nível da aplicação, do host e da rede, e as contramedidas recomendadas para lidar com cada uma delas.

O modulo não traz uma lista exaustiva de ameaças, mas destaca as principais. Com estas informações e conhecimento de como um invasor trabalha, você poderá identificar outras ameaças.

É preciso conhecer as ameaças com maior probabilidade de causar impacto em seu sistema para que você possa construir modelos de ameaças eficazes. Estes modelos de ameaças serão abordados no modulo, "Elaborando um Modelo de Ameaça." (em inglês).

Para tirar maior proveito deste módulo:

• Familiarize-se com ameaças específicas que afetam a sua rede, host e aplicação. As ameaças são diferentes para diversas partes do seu sistema, apesar dos objetivos dos invasores serem os mesmos.

• Use as ameaças para identificar riscos e criar um plano para conter estas ameaças.

• Aplique contramedidas para lidar com as vulnerabilidades. As contramedidas serão resumidas neste modulo. Use a Parte III, "Construindo Aplicações Web Seguras," e a Parte IV, "Protegendo Sua Rede, Host e Aplicação," deste guia para detalhes sobre a implementação de contramedidas.

Ao criar, construir e proteger seus sistemas, leve em consideração as ameaças descritas neste modulo. Estas ameaças existem independente da plataforma ou das tecnologias usadas.

Nesta página

Antes de Começar
Anatomia de um Ataque
Compreendendo as Categorias de Ameaças
Contramedidas e Ameaças na Rede
Contramedidas e Ameaças na Aplicação
Validação da Entrada
Autenticação
Autorização
Gerenciamento da Configuração
Dados Confidenciais
Gerenciamento da Sessão
Criptografia
Manipulação de Parâmetros
Gerenciamento de Exceções
Auditoria e Registro
Sumário
Recursos Adicionais

Antes de Começar

Antes de começar o processo de elaboração de um modelo de ameaça, é importante conhecer a seguinte terminologia básica:

• Recurso. Um recurso de valor como os dados num banco de dados ou num sistema de arquivos, ou um recurso do sistema.

• Ameaça. Uma ocorrência em potencial - mal-intencionada ou não - que pode danificar um recurso.

• Vulnerabilidade. Uma fraqueza que possibilita uma ameaça.

• Ataque (ou exploração). Uma ação tomada para danificar um recurso.

• Contramedida. Uma medida que lida com uma ameaça e que mitiga os riscos.

Anatomia de um Ataque

Conhecendo as abordagens comuns usadas pelos invasores para atingir sua aplicação Web, você estará mais bem preparado para tomar medidas defensivas porque saberá com o que está lidando. As etapas básicas da metodologia de um invasor estão resumidas abaixo e ilustradas na Figura 1:

• Pesquisar e avaliar

• Explorar e penetrar

• Escalar privilégios

• Manter acesso

• Negar serviço

Figura 1. Etapas básicas para a metodologia de ataque

Pesquisar e Avaliar

A pesquisa e a avaliação do alvo em potencial são feitas seqüencialmente. O primeiro passo dado por um invasor é geralmente a pesquisa do alvo em potencial para identificar e avalizar suas características. Estas características podem incluir seus serviços e protocolos suportados com vulnerabilidades em potencial e pontos de entrada. O invasor usa estas informações recolhidas na pesquisa e avaliação para planejar um ataque inicial.

Por exemplo, um invasor pode detectar uma vulnerabilidade de scripting entre sites (cross-site scripting - XSS) testando para ver se qualquer controle numa página da web ecoa de volta um output.

Explorar e Penetrar

Após ter pesquisado um alvo em potencial, o próximo passo é explorar e penetrar. Se a rede e o host estiverem totalmente seguros, sua aplicação (a porta de entrada) irá se tornar o próximo canal para ataque.

Para um invasor, a maneira mais fácil para penetrar uma aplicação é através da mesma entrada que legitima o usuário - por exemplo, através de uma das páginas de logon da aplicação ou uma página que não requeira autenticação.

Escalar Privilégios

Após conseguirem comprometer uma aplicação ou rede, talvez injetando códigos numa aplicação ou criando uma sessão autenticada com o sistema operacional Microsoft® Windows® 2000, os invasores imediatamente tentarão escalar os privilégios. Especificamente, eles procuram por privilégios administrativos fornecidos por contas pertencentes a um grupo de Administradores. Eles também buscam o alto nível de privilégios oferecidos pela conta do sistema local.

O uso de contas de serviços com menos privilégios em toda a sua aplicação é uma forma de defesa básica contra ataques de escalação. Além disso, muitos ataques de escalação de privilégios de nível de rede demandam uma sessão de logon interativo.

Manter Acesso

Após ganhar acesso a um sistema, os próximos passos dados por um invasor são buscar do acesso fácil no futuro e apagar os seus rastros. As abordagens mais comuns para facilitar o acesso futuro incluem programas de instalação de um back-door ou o uso de uma conta existente que está menos protegida. Apagar os rastros geralmente envolve limpar logs e esconder ferramentas. Desta forma, logs de auditoria são alvos primordiais para o invasor.

Arquivos registrados devem ser protegidos, e devem ser analisados regularmente. A análise dos arquivos registrados pode muitas vezes revelar sinais de uma tentativa de entrada forçada antes que ocorra algum prejuízo.

Negar Serviço

Os invasores que não conseguem ganhar acesso muitas vezes armam um ataque para negar serviço e assim evitar que outras pessoas utilizem a aplicação. Para outros invasores, a opção de negar serviço é o principal objetivo desde o princípio. Um exemplo é o ataque de inundação (flooding) SYN, onde o invasor usa um programa para enviar uma inundação de solicitações TCP SYN para encher a fila de conexão pendente no servidor. Isto faz com que outros usuários não possam estabelecer conexões de rede.

Compreendendo as Categorias de Ameaças

Apesar de existirem muitas variações de ataques específicos e de técnicas de ataque, é útil pensar nestas ameaças buscando saber o que o invasor está tentando alcançar. Isto tira o foco da identificação de todo e qualquer ataque específico - o que é realmente apenas um meio para um fim - e coloca o foco nos resultados finais de possíveis ataques.

STRIDE

As ameaças enfrentadas pela aplicação podem ser categorizadas com base nos objetivos e propósitos dos ataques. O conhecimento funcional destas categorias de ameaças pode ajudá-lo a organizar uma estratégia de segurança para que você tenha reações planejadas para as ameaças. STRIDE são as iniciais usadas na Microsoft para categorizar diferentes tipos de ameaças. STRIDE significa:

• Spoofing. Spoofing (falsificação) é a tentativa de ganhar acesso a um sistema usando uma identidade falsa. Isto pode ser feito usando credenciais roubadas ou um endereço falso de IP. Após o invasor ter conseguido ganhar acesso como um usuário legítimo ou host, a elevação ou o abuso de privilégios usando a autorização pode começar.

• Tampering. Tampering (manipulação) é a modificação não autorizada dos dados, por exemplo, conforme fluem através da rede entre dois computadores.

• Repudiation. Repudiation (repúdio) é a habilidade de usuários (legítimos ou não) de negar que tenham executado ações ou transações específicas. Sem a auditoria adequada, ataques de repudiation são difíceis de serem provados.

• Information disclosure. Information disclosure (revelação de informações) é a exposição não autorizada de dados privados. Por exemplo, um usuário visualiza o conteúdo de uma tabela ou arquivo não autorizado, ou monitora dados transmitidos em texto puro através de uma rede. Alguns exemplos de vulnerabilidades de information disclosure incluem o uso de campos escondidos, comentários incorporados em páginas da web que contém strings (seqüências) de conexão com um banco de dados e detalhes da conexão, e uma manipulação fraca de exceções que pode fazer com que detalhes do sistema interno sejam revelados ao cliente. Qualquer uma destas informações pode ser muito útil para o invasor.

• Denial of service. Denial of service (negação de serviço) é o processo que torna um sistema ou aplicação indisponível. Por exemplo, um ataque de negação de serviço pode ser feito com o bombardeamento de solicitações que consomem todos os recursos disponíveis do sistema ou com a transmissão de dados de entrada defeituosos que podem acabar com o processo de uma aplicação.

• Elevation of privilege. Elevation of privilege (elevação de privilégio) ocorre quando um usuário com privilégios limitados assume a identidade de um usuário privilegiado para ganhar acesso a uma aplicação. Por exemplo, um invasor com privilégios limitados pode elevar seu nível de privilégio para comprometer e tomar o controle de uma conta ou processo altamente privilegiado.

Ameaças e Contramedidas do STRIDE

Cada categoria de ameaça descrita no STRIDE possui um conjunto de técnicas de contramedidas que devem ser usadas para reduzir riscos. Estas técnicas foram resumidas na Tabela 1. A contramedida apropriada depende do ataque específico. Outras ameaças, ataques e contramedidas que se aplicam à rede, ao host e às aplicações serão apresentadas posteriormente neste módulo.

Tabela 1 Ameaças e Contramedidas do STRIDE

Ameaça	Contramedidas
Spoofing (falsificação) da identidade do usuário	Utilize autenticação forte. Não armazene segredos (por exemplo, senhas) em texto puro. Não transmita credenciais em texto puro por linha. Proteja os cookies de autenticação com Secure Sockets Layer (SSL).
Tampering (manipulação) de dados	Use assinatura e quebra de dados. Use assinaturas digitais. Use autorizações fortes. Use protocolos resistentes a tampering em todas as conexões de comunicação. Proteja as conexões de comunicação com protocolos que oferecem integridade de mensagens.
Repudiation (repúdio)	Crie trilhas de auditoria seguras. Use assinaturas digitais.
Information disclosure (revelação de informações)	Use autorização forte. Use encriptação forte. Proteja links de comunicação com protocolos que oferecem confidencialidade para mensagens. Não armazene segredos (por exemplo, senhas) em texto puro.
Denial of service (negação de serviço)	Use técnicas de controle de largura de banda e de recursos. Valide e filtre a entrada.
Elevation of privilege (elevação de privilégio)	Siga o princípio de privilégio mínimo e use contas de serviço menos privilegiadas para executar processos e acessar recursos.

Contramedidas e Ameaças na Rede

Os principais componentes que compõe sua infra-estrutura de rede são os roteadores, os firewalls, e os switches. Eles agem como guardiões protegendo seus servidores e suas aplicações contra ataques e invasões. Um invasor pode explorar dispositivos de rede mal configurados. Vulnerabilidades comuns incluem configurações fracas de instalação padrão, controles de acesso totalmente abertos, e dispositivos sem os últimos patches (atualizações) de segurança. Estas são as principais ameaças de rede:

• Acúmulo de Informações

• Sniffing

• Spoofing

• Seqüestro de Sessões

• Negação de serviço

Acúmulo de Informações

Dispositivos de rede podem ser descobertos e seus perfis podem ser traçados praticamente da mesma forma com que isto é feito em outros tipos de sistemas. Os invasores geralmente começam com a varredura de portas. Após identificarem portas abertas, eles utilizam enumeração e obtenção de banners para detectar tipos de dispositivos e determinar sistemas operacionais e versões de aplicações. Armado com estas informações, o invasor pode atacar as vulnerabilidades conhecidas que não foram ainda atualizadas com os patches de segurança.

Contramedidas para evitar o acúmulo de informações incluem:

• Configure roteadores para restringir suas reações às solicitações de footprinting.

• Configure sistemas operacionais que hospedam softwares de rede (por exemplo, firewalls de software) para evitar footprinting inabilitando protocolos não utilizados e portas desnecessárias.

Sniffing

Sniffing ou eavesdropping (escuta) é o ato de monitorar o tráfego na rede para dados como senhas em texto puro ou informações de configurações. Com um pacote simples de sniffing, um invasor pode facilmente ler todo o tráfego em texto puro. Além disso, os invasores também podem abrir pacotes encriptados quebrando algoritmos leves e podem decifrar a carga que você considera estar segura. O sniffing de pacotes requer um pacote sniffer no caminho da comunicação entre o cliente e o servidor.

Contramedidas para ajudar a evitar sniffing incluem:

• Use forte segurança física e segmentação adequada da rede. Este é o primeiro passo para evitar que o tráfego seja coletado localmente.

• Faça a encriptação total das comunicações, incluindo a autenticação de credenciais. Isto evita que os pacotes de sniffing possam ser usados por um invasor. SSL e IPSec (Internet Protocol Security) são exemplos de soluções de encriptação.

Spoofing

Spoofing (falsificação) é um meio de esconder a verdadeira identidade na rede. Para criar uma identidade enganosa, um invasor usa um falso endereço de fonte que não representa o verdadeiro endereço do pacote. O spoofing pode ser usado para esconder a fonte original de um ataque ou para contornar listas de controle de acesso de rede (network access control lists - ACLs) que estão posicionadas para limitar o acesso host baseado nas regras de endereço da fonte.

Apesar de pacotes de spoofing cuidadosamente preparados jamais permitirem o rastreamento até o responsável pelo envio original, uma combinação de regras de filtragem previne o surgimento de pacotes de spoofing a partir de sua rede, permitindo a você bloquear pacotes de spoofing óbvios.

Contramedidas para ajudar a evitar spoofing incluem:

• Filtrar pacotes no sentido interno que parecem vir de um endereço de IP interno, em seu perímetro.

• Filtrar pacotes no sentido externo que parecem ter sido originados de um endereço de IP local inválido.

Seqüestro de Sessões

Também conhecido como ataque de homem no meio (man in the middle), o seqüestro de sessões (session hijacking) engana um servidor ou cliente fazendo-os aceitar o host upstream como o host legítimo. Na verdade, o host upstream é um host do invasor que está manipulando a rede para que pareça ser o destino desejado.

Contramedidas para ajudara a evitar o seqüestro de sessões:

• Use negociação de sessão encriptada.

• Use canais de comunicação encriptados.

• Mantenha-se informado sobre patches para plataformas para ajustar vulnerabilidades TCP/IP, como seqüências de pacotes previsíveis.

Negação de Serviço

A negação de serviço nega aos usuários legítimos o acesso ao servidor ou aos serviços. O ataque de inundação de SYN é um exemplo comum de ataque de negação de serviço no nível da rede. É fácil de ser lançado e difícil de ser acompanhado. O objetivo do ataque é enviar mais solicitações para um servidor do que ele consegue lidar. O ataque explora a vulnerabilidade em potencial no mecanismo de estabelecimento de conexão TCP/IP e enche a fila de conexões pendentes do servidor.

Contramedidas para evitar a negação de serviço incluem:

• Aplique os últimos Service Packs.

• Dificulte o stack TCP/IP aplicando as configurações de registro apropriadas para aumentar o tamanho da fila de conexão TCP, para diminuir o período de estabelecimento da conexão, e para empregar mecanismos de backlog dinâmicos para garantir que a fila de conexão nunca seja esgotada.

• Use um sistema de detecção de intrusão (Intrusion Detection System, IDS) de rede porque estes sistemas podem detectar e reagir automaticamente aos ataques SYN.

Ameaças e Contramedidas no Host

As ameaças no host são direcionadas ao sistema de software sobre o qual suas aplicações são construídas. Isto inclui o Windows 2000, o Internet Information Services (IIS), o .NET Framework, e o SQL Server 2000, dependendo da função específica do servidor. As principais ameaças no nível do host são:

• Vírus, Cavalos de Tróia e Worms

• Footprinting (rastro)

• Profiling (elaboração de perfil)

• Quebra de senha

• Negação de serviço

• Execução de códigos arbitrários

• Acesso não autorizado

Vírus, Cavalos de Tróia e Worms

Um vírus é um programa criado para executar atos maliciosos e causar interrupções em seu sistema operacional ou aplicações. Um cavalo de tróia lembra um vírus, exceto que o código malicioso fica contido dentro do que parece ser um arquivo de dados inofensivo ou um programa executável. Um worm é similar a um cavalo de tróia exceto que ele se auto-replica de um servidor par ao outro. Os worms são difíceis de serem detectados porque eles não criam arquivos regulares que podem ser vistos. Eles muitas vezes são notados apenas quando começam a consumir recursos do sistema porque o sistema torna-se mais lento ou a execução de outros programas simplesmente pára. O worm Code Red é um dos mais notórios e que afligem o IIS; ele contava com uma vulnerabilidade no estouro do buffer em um determinado filtro ISAPI.

Apesar de estas ameaças tratarem na verdade de ataques, juntas elas representam uma ameaça considerável para as aplicações web, para os hosts destas aplicações, e para a rede usada para distribuir estas aplicações. O sucesso destes ataques em qualquer sistema é possível através de muitas vulnerabilidades como padrões fracos, bugs de software, erros de usuários, e vulnerabilidades inerentes em protocolos da Internet.

Contramedidas que podem ser usadas contra vírus, cavalos de tróia e worms incluem:

• Fique atualizado com os últimos pacotes de serviços e patches (atualizações) de softwares do sistema operacional.

• Bloqueie todas as portas desnecessárias no firewall e no host.

• Inabilite funcionalidades não utilizadas, incluindo protocolos e serviços.

• Endureça configurações padrões fracas.

Footprinting

Exemplos de footprinting são varreduras de portas, ping sweeps, e enumeração NetBIOS que podem ser usados por invasores para colher informações valiosas no nível do sistema, para ajudar a prepará-los para outros ataques significativos. O tipo de informação potencialmente revelada por footprinting inclui detalhes sobre contas, sistemas operacionais e outras versões de software, nomes de servidores, e detalhes de esquemas de bancos de dados.

Contramedidas para ajudar a evitar footprinting incluem:

• Desativar protocolos desnecessários.

• Fechar portas com a configuração de firewall apropriada.

• Usar filtros TCP/IP e IPSec para defesa em profundidade.

• Configurar IIS para evitar a revelação de informações através da obtenção de banners.

• Usar um IDS que possa ser configurado para detectar padrões de footprinting e rejeitar todo o tráfego suspeito.

Quebra de Senha

Se um invasor não consegue estabelecer uma conexão anônima com o servidor, ele terá que tentar estabelecer uma conexão autêntica. Para tanto, o invasor deve conhecer um nome de usuário e senha válidos. Se você utilizar nomes de conta padrão, estará facilitando o trabalho do invasor. Então, ele terá apenas que descobrir a senha para a conta. O uso de senhas fracas facilitará ainda mais o trabalho dele.

Contramedidas para ajudar a evitar a quebra de senha incluem:

• Use senhas fortes para todos os tipos de contas.

• Aplique políticas de bloqueio para contas de usuários finais para limitar o número de tentativas que podem ser feitas para adivinhar a senha.

• Não use nomes de contas padrão, e dê outro nome às contas padrão, como é feito com a conta do administrador e com as contas de usuários anônimos na Internet utilizadas em muitas aplicações web.

• Faça auditoria dos logins que falharam para buscar padrões de tentativas de quebra de senhas.

Negação de Serviço

A negação de serviço pode ser obtida através de muitos métodos direcionados para diversos alvos em sua infra-estrutura. No host, um invasor pode interromper o serviço com força bruta contra uma aplicação, ou um invasor pode conhecer uma vulnerabilidade que existe no serviço onde sua aplicação está hospedada ou no sistema operacional que é executado em seu servidor.

Contramedidas para ajudar a evitar a negação de serviço incluem:

• Configure suas aplicações, serviços, e sistema operacional tendo em mente a negação de serviço.

• Mantenha-se atualizado com patches e atualizações de segurança.

• Fortaleça o stack TCP/IP contra a negação de serviço.

• Certifique-se de que suas políticas de bloqueio de contas não podem ser exploradas para fazer o bloqueio de contas de serviços bem conhecidas.

• Certifique-se de que sua aplicação é capaz de lidar com grandes volumes de tráfego e que passagens estão posicionadas para lidar com cargas absurdamente altas.

• Reveja a funcionalidade do failover de sua aplicação.

• Use um IDS que possa detectar potenciais ataques de negação de serviço.

Execução de Código Arbitrário

Se um invasor pode executar códigos maliciosos em seu servidor, o invasor poderá comprometer os recursos do servidor ou preparar ataques futuros contra sistemas downstream. Os riscos apresentados pela execução de códigos arbitrários aumentarão caso o processo do servidor sob o qual o código do invasor está em execução for privilegiado. Vulnerabilidades comuns incluem configuração fraca e servidores sem patches que permitem ataques de estouro do buffer e de passagem do caminho, que podem levar à execução de código arbitrário.

Contramedidas para ajudar a evitar a execução de código arbitrário incluem:

• Configure o IIS para rejeitar URLs com "../" para evitar passagens no caminho.

• Tranque utilidades e comandos do sistema com ACLs restritas.

• Mantenha-se atualizado com patches e atualizações para garantir que estouros de buffer recém-descobertos sejam rapidamente cobertos.

Acesso Não Autorizado

Controles de acesso inadequados podem permitir que um usuário não autorizado tenha acesso a informações restritas ou execute operações restritas. Vulnerabilidades comuns incluem controles fracos de acesso IIS Web, incluindo permissões da web e permissões fracas NTFS.

Contramedidas para ajudar a evitar o acesso não autorizado incluem:

• Configure permissões da web seguras.

• Tranque arquivos e pastas com permissões NTFS restritas.

• Use os mecanismos de controle de acesso .NET Framework em suas aplicações ASP.NET, incluindo demandas para permissão principal e autorização da URL.

Contramedidas e Ameaças na Aplicação

Uma boa maneira de analisar ameaças no nível da aplicação é organizá-las em categorias de vulnerabilidade. As várias categorias usadas nas seções subseqüentes deste módulo e em todo este guia, juntas com as principais ameaças para a sua aplicação, estão resumidas na Tabela 2.

Tabela de Ameaças por Categoria de Vulnerabilidade da aplicação.

Categoria	Ameaças
Validação da Entrada	Estouro do buffer; scripting entre-sites; injeção SQL; canonicalização.
Autenticação	Escuta na rede, ataques de força bruta, ataques de dicionários, replay de cookies, roubo de credenciais.
Autorização	Elevação de privilégio; revelação de dados confidenciais; manipulação de dados; ataques enganadores.
Gerenciamento da configuração	Interfaces de acesso não autorizado à administração, acesso não autorizado aos depósitos de configuração; busca de dados de configuração em texto claro; falta de responsabilidade individual; contas ultraprivilegiadas de serviço e processo.
Dados confidenciais	Acesso a dados confidenciais armazenados; escuta na rede; manipulação de dados.
Gerenciamento de sessão	Seqüestro de sessão, replay de sessão, ataque "man in the middle"
Criptografia	Geração ou gerenciamento falho de chaves; encriptação fraca ou customizada.
Manipulação de parâmetros	Manipulação de string de consulta; manipulação de campo de formulário; manipulação de cabeçalho http.
Gerenciamento de exceções	Revelação de informações, negação de serviço.
Auditoria e registro	Usuário nega ter executado uma operação; invasor explora uma aplicação sem deixar rastros; invasor esconde seus rastros.

Validação da Entrada

A validação da entrada é um problema de segurança se um invasor descobrir que sua aplicação faz suposições sem fundamento sobre o tipo, extensão, formato, ou alcance dos dados de entrada. O invasor pode então fornecer cuidadosamente uma entrada fabricada que comprometerá sua aplicação.

Quando os pontos de entrada no nível do host e da rede estão totalmente seguros; as interfaces públicas expostas pela sua aplicação se tornam a única fonte de ataque. A entrada para a sua aplicação é um meio de testar o seu sistema e uma forma de executar códigos em benefício de um invasor. A sua aplicação confia cegamente na entrada? Se sim, sua aplicação pode estar suscetível a:

• Estouros do buffer

• Scripting entre-sites

• Injeção SQL

• Canonicalização

A seguinte seção examina estas vulnerabilidades em detalhes, incluindo o que as torna possível.

Estouros do buffer

As vulnerabilidades relacionadas ao estouro do buffer podem levar aos ataques de negação de serviço ou injeção de códigos. Um ataque de negação de serviço causa um travamento do processo; a injeção de códigos altera o endereço de execução do programa para executar o código injetado pelo invasor. O seguinte fragmento de código ilustra um exemplo comum de vulnerabilidade de estouro de buffer.

void SomeFunction( char *pszInput )

{
  char szBuffer[10];
  // Input is copied straight into the buffer when no type checking is performed
  strcpy(szBuffer, pszInput);
  . . .
}

Códigos gerenciados .NET não são suscetíveis a este problema porque os limites das matrizes são checados automaticamente sempre que uma matriz é acessada. Isto torna a ameaça do ataque de estouro do buffer em códigos gerenciados uma questão menos preocupante. Ainda é uma preocupação, no entanto, especialmente onde códigos gerenciados chamam objetos de APIs ou COM não gerenciados. Contramedidas para ajudar a evitar estouros do buffer incluem:

• Execute uma validação de entrada detalhada. Esta é a principal linha de defesa contra estouros do buffer. Apesar de poder haver um bug em sua aplicação que permita que a entrada esperada vá além dos limites de um contêiner, a entrada inesperada será a principal causa desta vulnerabilidade. Limite a entrada fazendo a sua validação por tipo, extensão, formato e alcance.

• Sempre que possível, limite o uso de códigos não gerenciados por sua aplicação, e inspecione cuidadosamente as APIs não gerenciadas para garantir que a entrada seja devidamente validada.

• Inspecione os códigos gerenciados que chamam as APIs não gerenciadas para garantir que apenas os valores apropriados possam ser transmitidos como parâmetros para a API não gerenciada.

• Use a bandeira /GS para compilar códigos desenvolvidos com o sistema de desenvolvimento do Microsoft Visual C++®. A bandeira /GS faz com que o compilador injete checagens de segurança no código compilado. Esta não é uma solução à prova de falhas ou uma substituição para o seu código de validação específico; ela, no entanto, protege os seus códigos contra ataques comuns de estouro do buffer. Para mais informações, veja a documentação do produto .NET Framework na página: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vclrfGSBufferSecurity.asp (em inglês) e o artigo do Microsoft Knowledge Base 325483 "Support WebCast: Compiler Security Checks: The /GS compiler switch" na página: https://support.microsoft.com/default.aspx?scid=325483 (em inglês).

Exemplo de uma Injeção de Código através dos Estouros do Buffer

Um invasor pode explorar uma vulnerabilidade de estouro do buffer para injetar códigos. Com este ataque, um usuário mal intencionado explora um buffer não checado num processo fornecendo um valor de entrada cuidadosamente construído que reescreve o stack do programa e altera as funções do endereço de retorno. Isto causa uma execução que pula para o código injetado do invasor.

O código do invasor geralmente acaba sendo executado sob o contexto de segurança do processo. Isto enfatiza a importância do uso de contas de processo menos privilegiadas. Se o segmento atual está personificando, o código do invasor acaba sendo executado sob o contexto de segurança definido pelo token de personificação do segmento. A primeira coisa que um invasor geralmente faz é chamar a API RevertToSelf para reverter o contexto de segurança no nível do processo, que o invasor espera que tenha privilégios mais altos.

Certifique-se de validar a entrada para tipo e extensão, especialmente antes de chamar códigos não gerenciados porque eles são particularmente suscetíveis a estouros do buffer.

Scripting Entre Sites (XSS)

Um ataque XSS pode fazer com que códigos arbitrários sejam executados no navegador de um usuário enquanto o navegador está conectado a um site confiável da web. O ataque tem como alvo os usuários de sua aplicação e não a aplicação em si, mas ele se utiliza dela como um veículo para o ataque.

Como o código do script pode ser obtido através de download pelo navegador a partir de um site confiável, o navegador não tem como saber que o código não é legítimo. As zonas de segurança do Internet Explorer não oferecem defesas. Como o código do invasor tem acesso aos cookies associados com o site confiável e estão armazenados no computador do usuário local, os cookies de autenticação de um usuário geralmente são o alvo do ataque.

Exemplos de Scripting Entre Sites

Para iniciar o ataque, o invasor deve convencer o usuário a clicar num hyperlink cuidadosamente criado, por exemplo, incorporando um link num e-mail enviado para o usuário ou adicionando um link malicioso a um posting de um fórum de discussões. O link direciona para uma página vulnerável em sua aplicação que ecoa a entrada invalidada de volta para o navegador na corrente de output HTML. Por exemplo, considere os dois links seguintes.

Este é um link legítimo:

www.yourwebapplication.com/logon.aspx?username=bob

Este é um link malicioso:

www.yourwebapplication.com/logon.aspx?username=<script>alert
('hacker code')</script>

Se a aplicação web pegar a série de consulta, falhar ao validado adequadamente, e retorná-lo ao navegador, o código do script é executado no navegador. O exemplo anterior mostra uma mensagem pop-up inofensiva. Com o script apropriado, o invasor pode facilmente extrair o cookie de autenticação do usuário, publicá-lo em seu site, e subseqüentemente fazer uma solicitação para o site alvo como se fosse o usuário autenticado.

Contramedidas para evitar XSS incluem:

• Execute uma validação cuidadosa da entrada. Suas aplicações devem garantir que a entrada de seqüências de consultas, campos de formulários, e os cookies sejam válidos para a aplicação. Considere toda a entrada de usuário potencialmente malicioso, e filtre ou esterilize para o contexto do código downstream. Valide toda a entrada para valores válidos conhecidos e então rejeite qualquer outra entrada. Use expressões regulares para validar dados de entrada recebidos através de seqüências de consultas, cookies e campos de formulários HTML.

• Use funções HTMLEncode e URLEncode para codificar qualquer output que inclua a entrada de usuário. Isto converte scripts executáveis em HTML inofensivo.

Injeção SQL

Um ataque de injeção SQL explora as vulnerabilidades na validação de entrada para executar comandos arbitrários no banco de dados. Isto pode ocorrer quando a sua aplicação usa a entrada para construir declarações dinâmicas do SQL para acessar o banco de dados. Pode ocorrer também caso o seu código utilize procedimentos armazenados que são seqüências transmitidas que contêm entrada não filtrada de usuários. Com um ataque de injeção SQL, o invasor pode executar comandos arbitrários no banco de dados. O problema é ampliado se a aplicação usa uma conta ultra privilegiada para se conectar ao banco de dados. Nesta instância, é possível usar o servidor do banco de dados para executar comandos do sistema operacional e potencialmente comprometer outros servidores, além de ser capaz de buscar, manipular e destruir dados.

Exemplo de Injeção SQL

Sua aplicação pode estar suscetível a ataques de injeção SQL quando você incorpora entradas não válidas de usuários em consultas do banco de dados. Mais suscetível ainda são os códigos que constroem declarações dinâmicas do SQL com entrada não filtrada de usuários. Considere o seguinte código:

SqlDataAdapter myCommand = new SqlDataAdapter(
         "SELECT * FROM Users 
          WHERE UserName ='" + txtuid.Text + "'", conn);

Os invasores podem injetar SQL ao finalizarem a declaração intencionada do SQL com o caractere aspa única, seguido do caractere ponto e virgula para começar um novo comando, e então executar o comando de sua escolha. Considere a seguinte série de caracteres inseridas no campo txtuid.

'; DROP TABLE Customers-

Isto resulta na seguinte declaração sendo submetida ao banco de dados para execução.

SELECT * FROM Users WHERE UserName=''; DROP TABLE Customers --'

Isto deleta a tabela Customers, assumindo que o login da aplicação possui permissões suficientes no banco de dados (outra razão para usar um login com menos privilégio no banco de dados). As linhas duplas (--) denotam um comentário do SQL e é usado para comentar qualquer outro caractere adicionado pelo programador, como a aspa deixada.

Nota O ponto e vírgula não é na verdade necessário. O SQL Server executará dois comandos separados por espaços.

Outros truques mais sutis podem ser desempenhados. O fornecimento desta entrada no campo txtuid:

' OR 1=1-

cria este comando:

SELECT * FROM Users WHERE UserName='' OR 1=1-

Como 1=1 é sempre verdadeiro, o invasor busca qualquer fileira de dados da tabela do usuário.

Contramedidas para evitar a injeção SQL incluem:

• Execute validação cuidadosa da entrada. Sua aplicação deve validar sua entrada antes de enviar uma solicitação para o banco de dados.

• Use os procedimentos armazenados parametrizados para acesso ao banco de dados para garantir que as seqüências de entrada não sejam tratadas como declarações executáveis. Se você não puder usar os procedimentos armazenados, use os parâmetros do SQL quando for construir comandos do SQL.

• Use contas com menos privilégios para se conectar ao banco de dados.

Canonicalização

As formas diferentes de entrada determinadas pelo mesmo nome padrão (nome canônico), são chamadas de canonicalização. Os códigos são particularmente suscetíveis às questões de canonicalização se são tomadas decisões de segurança com base no nome de um recurso que é transmitido para o programa como uma entrada. Arquivos, caminhos, e URLs são tipos de recursos vulneráveis à canonicalização porque em cada caso existem muitas maneiras diferentes de se representar o mesmo nome. Os nomes de arquivos também são problemáticos. Por exemplo, um único arquivo poderia ser representado como:

c:\temp\somefile.dat
somefile.dat
c:\temp\subdir\..\somefile.dat
c:\  temp\   somefile.dat
..\somefile.dat

Em condições ideais, o seu código não aceita nomes de arquivos de entrada. Se ele aceitar, o nome deve ser convertido para a sua forma canônica anterior da tomada de decisões de segurança, como se o acesso tivesse sido concedido ou negado àquele arquivo específico.

Contramedidas para lidar com questões de canonicalização incluem:

• Evite nomes de arquivos de entrada sempre que possível e ao invés disso use caminhos de arquivos absolutos que não podem ser alterados pelo usuário final.

• Certifique-se de que os nomes de arquivos sejam bem formados (se for absolutamente necessário aceitar nomes como entrada) e os valide dentro do contexto de sua aplicação. Por exemplo, verifique se eles estão dentro da hierarquia do diretório de sua aplicação.

• Certifique-se de que a codificação de caracteres está determinada corretamente para limitar como a entrada pode ser representada. Verifique se o Web.config de sua aplicação está configurada nos atributos requestEncoding e responseEncoding no elemento <globalization>.

Autenticação

Dependendo dos seus requisitos, existem diversas opções de mecanismos de autenticação disponíveis. Se eles não forem escolhidos e implementados corretamente, o mecanismo de autenticação pode expor vulnerabilidades que os invasores podem explorar para ganharem acesso ao seu sistema. As principais ameaças que exploram as vulnerabilidades da autenticação são:

• Escuta na rede

• Ataques de força bruta

• Ataques de dicionário

• Ataques de replay de cookies

• Roubo de credenciais

Escuta na rede

Se credenciais de autenticação forem transmitidas em texto puro do cliente para o servidor, um invasor armado com software rudimentar de monitoramento de rede num host da mesma rede pode capturar o tráfego e obter nomes e senhas de usuários.

Contramedidas para evitar a escuta na rede incluem:

• Use mecanismos de autenticação que não transmitem a senha através da rede, como o protocolo Kerberos ou a autenticação do Windows.

• Certifique-se de que as senhas serão encriptadas (se for absolutamente necessário transmiti-las através da rede) ou use um canal de comunicação encriptado, por exemplo, com SSL.

Ataques de Força Bruta

Os ataques de força bruta dependem do poder computacional para descobrir senhas quebradas ou outros segredos com quebra ou encriptação. Para mitigar o risco, utilize senhas fortes.

Ataques de Dicionário

Este ataque é usado para a obtenção de senhas. A maioria dos sistemas de senhas não armazena senhas encriptadas ou em texto puro. Eles evitam senhas encriptadas porque uma chave comprometida leva ao comprometimento de todas as senhas no armazém de dados. Chaves perdidas significam que todas as senhas estão invalidadas.

A maioria das implementações armazenadas de usuários tem hashes de senhas (ou passoword digests). Os usuários são autenticados reprocessando o pedaço baseado no valor da senha fornecido pelo o usuário e comparando-o com o pedaço do valor armazenado no banco de dados. Se um invasor conseguir obter a lista de hashes de senhas, um ataque de força bruta pode ser usado para descobrir os hashes das senhas.

Com o ataque de dicionário, um invasor usa um programa para passar todas as palavras de um dicionário (ou de diversos dicionários em línguas diferentes) e computa a quebra para cada palavra. O pedaço resultante é comparado com o valor no armazém de dados. Senhas fracas como "Corinthians" (um time favorito) ou "Mustang" (um carro favorito) serão descobertas rapidamente. Senhas fortes como "?oCeNUnkVay6bMnhçEnHA!", são menos passíveis de serem descobertas.

Nota Assim que o invasor tiver obtido a lista de hashes de senhas, o ataque de dicionário pode ser executado offline e não requer interação com a aplicação.

Contramedidas para evitar ataques de dicionário incluem:

• Use senhas fortes que sejam complexas, que não sejam palavras normais e que contenham uma mistura de maiúsculas, minúsculas, números, e caracteres especiais.

• Armazene hashes não reversíveis de senhas no depósito do usuário.Além disso, combine um valor de salt (um número aleatório forte criptografado) com a quebra da senha.

Para mais informações sobre o armazenamento de hashes de senhas com sal adicional, veja o módulo, "Construindo um Acesso Seguro aos Dados." (em inglês)

Ataques de Replay de Cookies

• Com este tipo de ataque, o invasor captura o cookie de autenticação do usuário monitorando o software e faz o seu replay para a aplicação para ganhar acesso sob uma falsa identidade.

• Contramedidas para evitar o replay de cookies incluem:

• Use um canal de comunicação encriptado fornecido pelo SSL sempre que um cookie de autenticação for transmitido.

• Use um intervalo (timeout) de cookies para um valor que força a autenticação após um intervalo de tempo relativamente curto. Apesar não evitar ataques de replay, esta medida reduz o intervalo de tempo no qual o invasor pode fazer o replay de uma solicitação sem ser forçado a re-autenticar porque o tempo da sessão foi esgotado.

Roubo de Credenciais

Se a sua aplicação implementa o seu próprio armazém de usuários contendo nomes e senhas de contas de usuários, compare sua segurança com os armazéns de credenciais fornecidos pela plataforma, por exemplo, um serviço de diretório do Microsoft Active Directory® ou o armazém de usuários do Security Accounts Manager (SAM). O histórico do navegador e do cache também podem armazenar informações de login de usuários para uso futuro. Se o terminal for acessado por outra pessoa que não o usuário que havia feito o logon, e a mesma página for aberta, o login salvo estará disponível.

Contramedidas para evitar o roubo de credenciais incluem:

• Use e reforce o uso de senhas fortes.

• Armazene verificadores de senhas na forma de hashes com sal adicionado.

• Reforce o trancamento de contas para contas de usuários finais após certo número de tentativas.

• Para barrar a possibilidade do cache do navegador permitir o acesso do login, crie funcionalidade que permite ao usuário escolher não salvar as credenciais, ou force esta funcionalidade como uma política padrão.

Autorização

Com base na identidade do usuário ou na função de membro, a autorização para um determinado recurso é concedida ou negada. As principais ameaças que exploram as vulnerabilidades da autorização incluem:

• Elevação de privilégio

• Revelação de dados confidenciais

• Manipulação de dados

• Ataques enganosos

Elevação de Privilégio

Ao criar um modelo de autorização, é preciso considerar a ameaça de um invasor tentando elevar os privilégios para uma conta poderosa como um membro do grupo de administradores locais ou conta do sistema local. Ao fazer isto, o invasor é capaz de ter controle total sobre a aplicação e máquina local. Por exemplo, com a programação clássica ASP, a chamada da API RevertToSelf a partir de um componente pode fazer com que o segmento em execução seja executado como a conta do sistema local com maior poder privilégios na máquina local.

A principal contramedida que pode ser usada para evitar a elevação de privilégio é o uso de processos, serviços e contas de usuários com privilégio mínimo.

Revelação de Dados Confidenciais

A revelação de dados confidenciais pode ocorrer se dados desta natureza forem visualizados por usuários não autorizados. Dados confidenciais incluem dados de aplicações específicas como números de cartões de crédito, detalhes sobre empregados, registros financeiros, e outros juntos com dados de configuração da aplicação como credenciais de contas de serviço e seqüências de conexão de bancos de dados. Para evitar a revelação de dados confidenciais, é preciso protegê-los em armazéns persistentes como bancos de dados e arquivos de configuração, e durante o trânsito através da rede. Apenas usuários autenticados e autorizados poderão acessar os seus dados específicos. O acesso aos dados de configuração no nível do sistema deve estar restrito aos administradores.

Contramedidas para evitar a revelação de dados confidenciais incluem:

• Execute checagens de funções antes de permitir o acesso às operações com potencial para a revelação de dados confidenciais.

• Use ACLs fortes para proteger recursos do Windows.

• Use encriptação padrão para armazenar dados confidenciais em arquivos de configuração e em bancos de dados.

Manipulação de Dados

A manipulação (tampering) de dados trata-se da modificação não autorizada de dados.

Contramedidas para evitar a manipulação de dados incluem:

• Use controles fortes de acesso para proteger dados em armazéns persistentes para garantir que apenas usuários autorizados possam acessar e modificar os dados.

• Use segurança baseada em funções para diferenciar os usuários que podem visualizar os dados daqueles que podem modificá-los.

Ataques enganosos

Um ataque enganoso (luring) ocorre quando uma entidade (usuário, grupo ou recurso), com poucos privilégios, faz com que outra, com mais privilégios, execute uma ação em seu nome.

Para barrar esta ameaça, é preciso restringir o acesso a códigos de confiança com a autorização adequada. O uso da segurança de acesso a códigos do .NET Framework ajuda neste sentido, ao autorizar um código de chamada sempre que um recurso seguro é acessado ou uma operação privilegiada é executada.

Gerenciamento da Configuração

Muitas aplicações suportam interfaces de gerenciamento de configuração e funcionalidade que permite aos operadores e administradores alterarem parâmetros de configuração, atualizarem o conteúdo de sites, e executarem procedimentos de manutenção rotineiros. As principais ameaças ao gerenciamento da configuração incluem:

• Acesso não autorizado às interfaces de administração

• Acesso não autorizado aos armazéns de configurações

• Retorno de segredos de configuração em texto puro

• Falta de responsabilidade individual

• Contas ultraprivilegiadas de serviços e processos

Acesso Não Autorizado às Interfaces de Administração

Interfaces de administração geralmente são fornecidas através de páginas adicionais da web ou aplicações da web separadas que permitem aos administradores, operadores, e desenvolvedores de conteúdo gerenciarem o conteúdo e a configuração do site. Tais interfaces de administração devem estar disponíveis apenas para usuários restritos e autorizados. Usuários mal-intencionados capazes de acessar uma função de gerenciamento da configuração podem desfigurar um site, acessar sistemas e bancos de dados downstream, ou tirar a ação da aplicação através da corrupção dos dados de configuração.

Contramedidas para evitar o acesso não autorizado às interfaces de administração incluem:

• Minimize o número de interfaces de administração.

• Use autenticação forte, por exemplo, com certificados.

• Use autorização forte com guardiões múltiplos.

• Considere o suporte apenas da administração local. Se a administração remota for absolutamente essencial, use canais encriptados, por exemplo, com tecnologia VPN ou SSL, dada a natureza confidencial dos dados transmitidos através de interfaces administrativas. Para reduzir ainda mais o risco, considere o uso de políticas IPSec para limitar a administração remota aos computadores da rede interna.

Acesso Não Autorizado aos Repositórios de Configurações

Dada a natureza confidencial dos dados mantidos nos repositórios de configurações, é preciso garantir que estes locais estejam adequadamente protegidos.

Contramedidas para proteger os repositórios de configurações incluem:

• Configure ACLs restritas nos arquivos de configuração baseados em texto como Machine.config e Web.config.

• Mantenha repositórios de configurações customizados fora do espaço da web. Isto remove o potencial para download de configurações de servidores web para explorar suas vulnerabilidades.

Retorno de Segredos de Configuração em Texto puro

Restringir o acesso para o armazém de configurações é absolutamente necessário. Por ser um importante mecanismo de defesa completo, deve-se tentar encriptar dados confidenciais como seqüências de conexão e senhas. Isto ajuda a evitar que invasores externos obtenham dados de configuração confidenciais. Isto também evita que administradores e funcionários internos mal-intencionados obtenham dados confidenciais como seqüências de conexão de bancos de dados e credenciais de contas que podem permitir que eles tenham acesso a outros sistemas.

Falta de Responsabilidade Individual

A falta de auditoria e de registros de mudanças feitas nas informações sobre as configurações ameaça a habilidade para identificação sobre quando as mudanças foram feitas e quem fez estas mudanças. Quando uma mudança de transgressão é feita por um erro de um operador honesto ou por uma mudança mal-intencionada para garantir acesso privilegiado, uma ação deve ser tomada, em primeiro lugar, para corrigir a alteração. Então, devem ser aplicadas medidas preventivas para evitar que alterações de transgressão possam ser introduzidas da mesma maneira. Lembre-se que a auditoria e os registros podem ser driblados por uma conta compartilhada; isto se aplica às contas administrativas e às contas de serviço/aplicação/usuário. As contas administrativas não podem ser compartilhadas. As contas de serviço/aplicação/usuário devem ser destinadas a um nível que permita a identificação de uma única fonte de acesso utilizando a conta, e que contenha qualquer dano aos privilégios concedidos àquela conta.

Contas Ultra Privilegiadas de Serviços e Aplicações

Se as contas de serviços e aplicações têm acesso garantido para efetuar alterações nas informações de configuração no sistema, elas podem ser manipuladas por um invasor para fazer isso. O risco desta ameaça pode ser mitigado através da adoção de uma política de uso de contas de aplicações e serviços menos privilegiadas. Seja cauteloso ao conceder às contas a habilidade de modificar suas próprias informações de configuração a não ser que seja explicitamente necessário por design.

Dados Confidenciais

Dados sensíveis estão sujeitos a uma variedade de ameaças. Ataques que tentam visualizar ou modificar dados confidenciais podem ter como alvo redes e armazéns de dados persistentes. As principais ameaças aos dados confidenciais incluem:

• Acesso a dados confidenciais armazenados

• Escuta na rede

• Manipulação de dados

Acesso a Dados Confidenciais Armazenados

É preciso proteger dados confidenciais armazenados para evitar que um usuário - mal intencionado ou não - tenha acesso a eles.

Contramedidas para proteger dados confidenciais armazenados incluem:

• Use ACLs restritas nos repositórios de dados persistentes que contém dados confidenciais.

• Armazene dados encriptados.

• Use autorização baseada em função e identidade para garantir que apenas o usuário ou usuários com o nível apropriado de autoridade terá permissão de acesso aos dados confidenciais. Use segurança baseada em função para diferenciar os usuários que podem visualizar os dados daqueles que podem modificá-los.

Escuta na rede

Os dados em HTTP para aplicações web viajam através das redes em texto puro e estão sujeitos à ataques de escuta na rede, onde um invasor utiliza um software de monitoramento de rede para capturar e potencialmente modificar dados confidenciais.

Contramedidas para evitar a escuta na rede e proporcionar privacidade incluem:

• Encriptação dos dados.

• Uso de um canal de comunicação encriptado, como o SSL, por exemplo.

Manipulação de Dados

A manipulação (tampering) de dados se refere à modificação não autorizada de dados, muitas vezes quando eles são transmitidos através da rede.

Uma contramedida para evitar a manipulação de dados é proteger os dados confidenciais transmitidos através da rede com protocolos resistentes à manipulação como os códigos de autenticação de mensagens quebradas (hashed message authentication codes - HMACs).

Um HMAC promove a integridade da mensagem da seguinte forma:

1. Quem envia a mensagem utiliza uma chave secreta compartilhada para criar uma quebra (hash) baseada na carga da mensagem.

2. Quem envia, transmite a quebra (hash) junto com a carga da mensagem.

3. Quem recebe usa a chave compartilhada para recalcular a quebra com base na carga da mensagem enviada. O recebedor então compara o novo valor de quebra com o valor de quebra transmitido. Se forem iguais, a mensagem então não pode ter sido manipulada.

Gerenciamento da Sessão

O gerenciamento de sessão para aplicações web é uma responsabilidade da camada de aplicação. A segurança da sessão é crítica para a segurança total da aplicação.

As principais ameaças no gerenciamento de sessão incluem:

• Seqüestro de sessão

• Replay de sessão

• Ataques "man in the middle"

Seqüestro de Sessão

Um ataque de seqüestro de sessão ocorre quando um invasor utiliza um software de monitoramento de rede para capturar o token (muitas vezes um cookie) de autenticação usado para representar a sessão de um usuário com uma aplicação. Com o cookie capturado, o invasor pode enganar a sessão do usuário e ganhar acesso à aplicação. O invasor possui nível de privilégios igual ao do usuário legítimo.

Contramedidas para evitar o seqüestro de sessões incluem:

• Use o SSL para criar um canal de comunicação e transmita o cookie de autenticação apenas através de uma conexão HTTPS.

• Implemente a funcionalidade do logout para permitir que um usuário finalize uma sessão que força a autenticação se outra sessão for iniciada.

• Certifique-se de limitar o período de expiração no cookie da sessão caso você não utilize o SSL. Apesar desta medida não evitar o seqüestro de sessão, ela reduz o tempo que uma janela fica disponível para o invasor.

Replay de Sessão

O replay da sessão ocorre quando um token da sessão do usuário é interceptado e submetido por um invasor para desviar do mecanismo de autenticação. Por exemplo, se o token da sessão estiver em texto puro em um cookie ou URL, um invasor poderá detectá-lo. O invasor então submete uma solicitação usando o token da sessão seqüestrada.

Contramedidas para ajudar a lidar com a ameaça de replay de sessão incluem:

• Re-autentique quando estiver executando funções críticas. Por exemplo, antes de executar uma transferência de dinheiro numa aplicação bancária, obrigue o usuário fornecer a senha da conta novamente.

• Finalize as sessões adequadamente, incluindo todos os tokens da sessão e os cookies.

• Crie uma opção "não se lembre de mim" que não permita que nenhum dos dados da sessão ser armazenados no cliente.

Ataques "Man in the Middle"

Um ataque "man in the middle" (homem no meio) ocorre quando o invasor intercepta mensagens enviadas entre você e a pessoa a quem a mensagem se destina. O invasor então altera a sua mensagem e a envia àquela pessoa. Quem recebe a mensagem, vê que ela veio de você, e age de acordo. Quando esta pessoa envia uma mensagem de volta, o invasor a intercepta, altera o seu conteúdo, e a devolve a você. Vocês dois jamais saberão que foram atacados.

Qualquer solicitação da rede envolvendo a comunicação entre cliente e servidor, incluindo solicitações na web, solicitações de Distributed Component Object Model (DCOM), e chamadas para componentes remotos e serviços web, estão sujeitas a ataques tipo "man in the middle".

Contramedidas para evitar ataques tipo "man in the middle" incluem:

• Use criptografia. Se você encriptar os dados antes de transmiti-los, o invasor ainda poderá interceptá-los, mas não poderá lê-los ou alterá-los. Se o invasor não puder lê-los, ele não saberá qual parte alterar. Se o invasor modificar cegamente sua mensagem encriptada, então a pessoa cuja mensagem é destinada não poderá decriptá-la corretamente e, como resultado disso, saberá que a mensagem foi adulterada.

• Use os Códigos de Autenticação de Mensagens Quebradas (Hashed Message Authentication Codes - HMACs). Se um invasor altera a mensagem, o recálculo do HMAC no recipiente falhará e os dados poderão ser rejeitados como inválidos.

Criptografia

A maioria das aplicações usa a criptografia para protegerem dados e garantir que eles permaneçam privados e inalterados. As principais ameaças envolvendo o uso da criptografia em suas aplicações são:

• Geração ou gerenciamento pobre de chaves

• Encriptação customizada ou fraca

• Enganação com o Checksum

Geração ou gerenciamento pobre de chave

Os invasores podem decriptar dados encriptados se tiverem acesso à chave de encriptação ou se puderem deduzi-la. Os invasores podem descobrir uma chave se as chaves forem gerenciadas de forma pobre ou se forem geradas de forma não-aleatória.

Contramedidas para lidar com a ameaça da geração e do gerenciamento pobre de chaves incluem:

• Use rotinas de encriptação embutidas que incluem o gerenciamento seguro de chaves. A interface de programação de aplicações de Proteção de Dados (Data Protection application programming interface - DPAPI) é um exemplo de um serviço de encriptação oferecido pelo Windows 2000 e em sistemas operacionais posteriores onde o sistema operacional gerencia a chave.

• Use funções fortes e aleatórias para geração de chaves e armazene a chave em um local restrito - por exemplo, numa chave de registro protegida com uma ACL restrita - se você utilizar um mecanismo de encriptação que requer a geração ou gerenciamento da chave.

• Faça a encriptação da chave usando o DPAPI para segurança extra.

• Altere a validade das chaves regularmente.

Encriptação Fraca ou Customizada

Um algoritmo de encriptação não oferecerá nenhuma segurança se a encriptação for violada ou estiver vulnerável a violação por força bruta. Algoritmos customizados são particularmente vulneráveis se não tiverem sido testados. Ao invés deles, use algoritmos de encriptação publicados e bem conhecidos que já resistiram a anos de ataques rigorosos e exames rigorosos.

Contramedidas que lidam com as vulnerabilidades de encriptação fraca ou customizada incluem:

• Não desenvolva os seus próprios algoritmos customizados.

• Use os serviços comprovados de criptografia fornecidos pela plataforma.

• Mantenha-se informado sobre algoritmos violados e as técnicas utilizadas para violá-los.

Enganação com o Checksum

Não confie nos hashes (quebras) que oferecem integridade de dados para mensagens transmitidas através das redes. Hashes como o Safe Hash Algorithm (SHA1) e o algoritmo de compressão do Message Digest (MD5) podem ser interceptados e alterados. Considere a seguinte mensagem de código UTF-8 base 64 com um Message Authentication Code (MAC) anexado.

Texto puro: Place 10 orders.
Hash: T0mUNdEQh13IO9oTcaP4FYDX6pU=

Se um invasor interceptar a mensagem ao monitorar a rede, ele poderá atualizar a mensagem e re-computar o hash (adivinhando o algoritmo que foi usado). Por exemplo, a mensagem poderia ser alterada para:

Texto puro: Place 100 orders.
Hash: oEDuJpv/ZtIU7BXDDNv17EAHeAU=

Quando os recebedores processam a mensagem, e executam o texto puro ("Place 100 orders") através do algoritmo em "hash", e então re-computam o hash, o hash que calcularam será igual àquele que o invasor computou.

Para barrar este ataque, use um MAC ou HMAC. O algoritmo padrão de encriptação de dados triplo de código de autenticação de mensagem (Message Authentication Code Triple Data Encryption Standard - MACTripleDES) computa um MAC, e o HMACSHA1 computa um HMAC. Ambos usam uma chave para produzir um checksum. Com estes algoritmos, um invasor precisa saber a chave para gerar um checksum que computaria corretamente no recebedor.

Manipulação de Parâmetros

Os ataques de manipulação de parâmetros compõem uma classe de ataque que depende da modificação dos dados do parâmetro enviados entre o cliente e a aplicação web. Isto inclui seqüências de consultas, campos de formulários, cookies, e cabeçalhos HTTP. As principais ameaças de manipulação de parâmetros são:

• Manipulação de seqüências de consultas

• Manipulação de campos de formulários

• Manipulação de Cookies

• Manipulação de cabeçalhos do HTTP

Manipulação de seqüências de consultas

Os usuários podem facilmente manipular os valores da seqüência de consultas transmitidos pelo HTTP GET do cliente para o servidor porque eles são exibidos na barra de endereços de URL do navegador. Se a sua aplicação depende dos valores da seqüência de consultas para tomar decisões de segurança, ou se os valores representam dados confidenciais como quantias monetárias, a aplicação torna-se vulnerável a ataques.

Contramedidas para lidar com as ameaças de manipulação de seqüências de consultas incluem:

• Evite usar parâmetros de seqüências de consultas que contenham dados confidenciais ou dados que podem influenciar a lógica da segurança no servidor. Ao invés disso, use um identificador de sessão para identificar o cliente e armazenar itens confidenciais na sessão no servidor.

• Escolha o POST HTTP ao invés do GET ao submeter formulários.

• Faça a encriptação de parâmetros de seqüências de consultas.

Manipulação de Campos de Formulários

Os valores dos campos de formulários em HTML são enviados em texto puro para o servidor usando o protocolo POST HTTP. Isto pode incluir campos de formulários visíveis ou não. Campos de formulários de qualquer tipo podem ser facilmente modificados e as rotinas de validação do lado do cliente podem ser contornadas. Como resultado, as aplicações que dependem de valores de entrada em campos de formulários para a tomada de decisões estão vulneráveis a ataques.

Para barrar a ameaça de manipulação de campos de formulários, ao invés de usar campos de formulários ocultos, use identificadores de sessão para fazer referência ao estado mantido no armazém de estado no servidor.

Manipulação de Cookies

Os cookies são suscetíveis à modificação pelo cliente. Isto é verdade tanto para cookies residentes na memória quanto para os persistentes. Diversas ferramentas estão disponíveis para ajudar um invasor a modificar os conteúdos de um cookie residente na memória. A manipulação de cookies é o ataque referente à modificação de um cookie, geralmente para ganhar acesso não autorizado a um site.

Apesar de o SSL proteger cookies em toda a rede, ele não evita que eles sejam modificados no computador do cliente. Para barrar a ameaça da manipulação de cookies, faça a encriptação ou use um HMAC com o cookie.

Manipulação de Cabeçalhos do HTTP

Os cabeçalhos do HTTP transmitem informações entre o cliente e o servidor. O cliente constrói cabeçalhos de solicitação enquanto o servidor constrói cabeçalhos de respostas. Se a sua aplicação depende dos cabeçalhos de solicitação para tomar uma decisão, então ela está vulnerável a ataques.

Não baseie suas decisões de segurança nos cabeçalhos do HTTP. Por exemplo, não confie no HTTP Referer para determinar de onde vem um cliente porque isto pode ser facilmente falsificado.

Gerenciamento de Exceções

Exceções que têm permissão para se propagar para o cliente podem revelar detalhes internos de implementação que não fazem o menor sentido para o usuário final, mas que são úteis para os invasores. As aplicações que não utilizam a manipulação de exceções ou que a implementam de forma pobre também estão sujeitas aos ataques de negação de serviços. As principais ameaças relacionadas à manipulação de exceções são:

• O invasor revela detalhes da implementação

• Negação de serviço

O invasor revela detalhes da implementação

Um dos recursos mais importantes do .NET Framework é que ele oferece detalhes ricos de exceções cujo valor é inestimável para os desenvolvedores. Se a mesma informação cair nas mãos de um invasor, ela pode ajudá-lo consideravelmente nas tarefas de explorar as vulnerabilidades em potencial, e de planejar ataques futuros. O tipo de informação que pode ser retornada inclui versões de plataformas, nomes de servidores, seqüências de comandos do SQL, e seqüências de conexão do banco de dados.

Contramedidas para ajudar a evitar que detalhes da implementação sejam revelados para o cliente incluem:

• Use a manipulação de exceções em toda a base de códigos de sua aplicação.

• Manipule e registre as exceções que têm permissão para serem propagadas nos limites da aplicação.

• Retorne ao cliente mensagens de erro inofensivas e genéricas.

Negação de serviço

Os invasores irão sondar uma aplicação da web, geralmente através da transmissão de uma entrada deliberadamente mal-formada. Eles geralmente têm dois objetivos em mente. O primeiro é causar exceções que revelem informações úteis, e o segundo é violar o processo de aplicação da web. Isto poderá ocorrer caso as exceções não sejam devidamente capturadas e manipuladas.

Contramedidas para ajudar a evitar a negação de serviço no nível da aplicação incluem:

• Valide cuidadosamente todos dos dados de entrada no servidor.

• Use a manipulação de exceções em toda a base de códigos de sua exceção.

Auditoria e Registro

A auditoria e o registro devem ser usados para ajudar a detectar atividades suspeitas como footprinting ou possivelmente tentativas de violação de senha antes de uma exploração ocorrer de fato. A auditoria e o registro também podem ajudar a lidar a ameaça de repúdio. É muito mais difícil para um usuário negar ter executado uma operação se uma série de entradas de registro sincronizada em diversos servidores indica que o usuário desempenhou aquela transação.

As principais ameaças relacionadas à auditoria e ao registro incluem:

• O usuário nega ter executado uma operação

• Os invasores exploram uma aplicação sem deixar rastros

• Os invasores apagam seus rastros

O usuário nega ter executado uma operação

A questão do repúdio está relacionada à um usuário que nega ter executado uma ação ou iniciado uma transação. É preciso que haja mecanismos de defesa prontos para garantir que todas as atividades dos usuários possam ser rastreadas e registradas.

Contramedidas para ajudar a evitar ameaças de repúdio são:

• Faça auditoria e registre as atividades no servidor web, no servidor do banco de dados, e também no servidor da aplicação, se estiver usando um.

• Registre eventos chave como transações e eventos de login e logout.

• Não utilize contas compartilhadas já que a fonte original não pode ser determinada.

Os invasores exploram uma aplicação sem deixar rastros

A auditoria no nível da aplicação e do sistema é necessária para garantir que atividades suspeitas não deixem de ser detectadas.

Contramedidas para detectar atividades suspeitas incluem:

• Registro de operações críticas no nível da aplicação.

• Use auditoria no nível da plataforma para eventos de login e logout, acesso ao sistema de arquivos, e tentativas mal-sucedidas de acesso a objetos.

• Faça o backup de arquivos registrados e analise-os regularmente para tentar encontrar sinais de atividades suspeitas.

Os invasores apagam seus rastros

Os seus arquivos registrados devem estar bem-protegidos para garantir que invasores não possam apagar seus rastros.

Contramedidas para ajudar a evitar que invasores apaguem seus rastros incluem:

• Proteja arquivos registrados usando ACLs restritas.

• Transfira arquivos registrados do sistema para longe de seus locais padrões.

Sumário

Estando ciente da abordagem tipicamente utilizada pelos invasores, bem como seus objetivos, você poderá aplicar as contramedidas de forma mais eficiente. Também é uma boa idéia usar uma abordagem tendo como base o objetivo ao considerar e identificar as ameaças, e usar o modelo STRIDE para categorizar as ameaças com base nos objetivos do invasor, por exemplo, falsificar identidade, manipular dados, negar serviço, elevar privilégios, etc. Isto permitirá um enfoque maior nas abordagens generalizadas que devem ser usadas para mitigar riscos, ao invés de focar na identificação de cada ataque possível, o que pode ser uma tarefa potencialmente demorada e inútil.

Este módulo apresentou as principais ameaças que têm o potencial de comprometimento de sua rede, da infra-estrutura do host, e das aplicações. O conhecimento destas ameaças, em conjunto com as contramedidas adequadas, fornece as informações essenciais para o processo de elaboração de modelos de ameaças. Este conhecimento permite ainda que você identifique as ameaças que são específicas ao seu cenário em particular e as priorize com base no grau do risco representado para o seu sistema. Este processo estruturado para a identificação e priorização das ameaças é chamado de elaboração de modelo de ameaça (threat modeling). Para mais informações, veja o módulo, "Elaboração de Modelos de Ameaça." (em inglês).

Recursos Adicionais

Para ler mais sobre este assunto, veja os seguintes recursos:

• Para mais informações sobre ameaças na rede e contramedidas, veja o módulo, "Protegendo Sua Rede."

• Para mais informações sobre ameaças no host e contramedidas, veja os módulos, "Protegendo Seu Servidor Web ,", "Protegendo Seu Servidor de Aplicações,", "Protegendo Seu Servidor de Banco de Dados," e, "Protegendo sua Aplicação do ASP.NET."

• Para mais informações sobre como lidar com as ameaças no nível da aplicação apresentadas neste módulo, veja os módulos de Construção na Parte III deste guia, "Construindo Aplicações da Web Seguras".

• Michael Howard e David LeBlanc, Writing Secure Code 2nd Edition. Microsoft Press, Redmond, WA, 2002

• Para mais informações sobre rastreamento e conserto de estouros do buffer, veja o artigo do MSDN, "Fix Those Buffer Overruns!" na página https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure05202002.asp