Ameaças e Contramedidas de Segurança Na Web

07/03/13 Ameaças e Contramedidas de Segurança na Web: Ameaças e Contramedidas de Segurança na Web
Ameaças e Contramedidas de
Segurança na Web
12 de 14 pessoas classificaram isso como útil
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.
technet.microsoft.com/pt-br/library/dd569900(d=printer).aspx 1/28
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.
Contramedida. Uma medida que lida com uma ameaça e que mitiga os riscos.
Início da página
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
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.
Início da página
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
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 Utilize autenticação forte.

identidade do usuário 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 Use assinatura e quebra de dados.

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 Use autorização forte.

(revelação de informações) 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 Use técnicas de controle de largura de banda e de recursos.

serviço) Valide e filtre a entrada.
Elevation of privilege (elevação Siga o princípio de privilégio mínimo e use contas de serviço menos
de privilégio) privilegiadas para executar processos e acessar recursos.
Início da página
Início da página
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,
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
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.
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.
Início da página
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 Estouro do buffer; scripting entre-sites; injeção SQL; canonicalização.

Entrada
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 Interfaces de acesso não autorizado à administração, acesso não autorizado aos depósitos de
da configuração; busca de dados de configuração em texto claro; falta de responsabilidade
configuração individual; contas ultraprivilegiadas de serviço e processo.
Dados Acesso a dados confidenciais armazenados; escuta na rede; manipulação de dados.

Dados Acesso a dados confidenciais armazenados; escuta na rede; manipulação de dados.
confidenciais
Gerenciamento Seqüestro de sessão, replay de sessão, ataque "man in the middle"

de sessão
Criptografia Geração ou gerenciamento falho de chaves; encriptação fraca ou customizada.
Manipulação Manipulação de string de consulta; manipulação de campo de formulário; manipulação de

de parâmetros cabeçalho http.
Gerenciamento Revelação de informações, negação de serviço.

de exceções
Auditoria e Usuário nega ter executado uma operação; invasor explora uma aplicação sem deixar rastros;
registro invasor esconde seus rastros.
Início da página
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);
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: http://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:
http://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

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>.
Início da página
Autenticação
Dependendo dos seus requisitos, existem diversas opções de mecanismos de autenticação disponíveis. Se eles nã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.
Início da página
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.
Início da página
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.
Início da página
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
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.
Início da página
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.
Início da página
Início da página
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.
Início da página
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.

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.
Início da página
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
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.
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.
Início da página
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.

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.
Início da página
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).
Início da página
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 http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/dncode/html/secure05202002.asp
Início da página
© 2013 Microsoft. Todos os direitos reservados.

Ameaças e Contramedidas de Segurança Na Web

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ameaças e Contramedidas de Segurança Na Web

Enviado por

Direitos autorais:

Formatos disponíveis

07/03/13 Ameaças e Contramedidas de Segurança na Web: Ameaças e Contramedidas de Segurança na Web

Ameaças e Contramedidas de Segurança na Web

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.

Como Usar Este Módulo

Para tirar maior proveito deste módulo:

Vulnerabilidade. Uma fraqueza que possibilita uma ameaça.

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

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

Compreendendo as Categorias de Ameaças

Information disclosure. Information disclosure (revelação de informações) é a exposição não autorizada de

Ameaças e Contramedidas do STRIDE

Tabela 1 Ameaças e Contramedidas do STRIDE

Spoofing (falsificação) da Utilize autenticação forte.

Tampering (manipulação) de Use assinatura e quebra de dados.

Repudiation (repúdio) Crie trilhas de auditoria seguras.

Information disclosure Use autorização forte.

Denial of service (negação de Use técnicas de controle de largura de banda e de recursos.

Contramedidas e Ameaças na Rede

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

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

Contramedidas para ajudar a evitar sniffing incluem:

Contramedidas para ajudar a evitar spoofing incluem:

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

Use negociação de sessão encriptada.

Use canais de comunicação encriptados.

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

Aplique os últimos Service Packs.

Ameaças e Contramedidas no Host

Vírus, Cavalos de Tróia e Worms

Profiling (elaboração de perfil)

Execução de códigos arbitrários

Acesso não autorizado

Vírus, Cavalos de Tróia e Worms

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.

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.

Contramedidas para ajudar a evitar a quebra de senha incluem:

Use senhas fortes para todos os tipos de contas.

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

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

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

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

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

Tranque utilidades e comandos do sistema com ACLs restritas.

Acesso Não Autorizado

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.

Contramedidas e Ameaças na Aplicação

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

Validação da Estouro do buffer; scripting entre-sites; injeção SQL; canonicalização.

Autorização Elevação de privilégio; revelação de dados confidenciais; manipulação de dados; ataques

Dados Acesso a dados confidenciais armazenados; escuta na rede; manipulação de dados.