Falhas comuns de aplicações web e métodos de ataques

Vejamos alguns métodos comuns de explorar as vulnerabilidades de uma aplicação ou site hospedado em um servidor web.

Misconfiguration

É muito fácil para o administrador inexperiente, mas bem-intencionado, configurar mal ou simplesmente se perder em uma configuração, que pode ser a opção que permite um ataque.

Para evitar que a configuração incorreta se torne um problema, certifique-se de que a função do servidor está corretamente definida. Planeje e avalie a configuração para garantir que ela irá fornecer a proteção necessária. Certifique-se também de rever as melhores práticas que fornecedores como a Microsoft oferecem sobre as etapas a serem tomadas para proteger um sistema.

Outra opção é usar scanners de vulnerabilidade para verificar possíveis problemas em um site ou aplicação da Web. Os scanners de vulnerabilidade podem fornecer orientação valiosa sobre onde os esforços devem ser concentrados.

Validação de Entrada

Validação de entrada é um mecanismo usado para verificar as informações de como elas são inseridas em uma aplicação. Normalmente, um usuário inserindo dados em um formulário ou site terá poucas ou nenhuma restrição colocadas sobre eles. Quando os dados são aceitos sem restrições, erros tanto intencionais como não intencionais podem ser inseridos no sistema e podem levar a problemas mais tarde. No entanto, com um mecanismo para validar entrada, é possível frustrar esses problemas, que incluem:

• Manipulação de banco de dados
• Corrupção de banco de dados
• Buffer overflows
• Dados inconsistentes

A falta de validação de entrada pode permitir ataques avançados como SQL Injection. Também é possível que outros ataques, como o XSS armazenado, possam ser possíveis pela falta de validação de entrada.

Um bom exemplo da falta de validação de entrada é uma caixa em um formulário onde um código postal deve ser inserido, mas na realidade ele aceitará qualquer dado. Em outros casos, aceitar os dados errados significará simplesmente que a informação pode ser inutilizável para o proprietário do site, mas pode causar falha no site ou manipular de forma errada a informação para revelar outras informações na tela.

Felizmente, este problema é relativamente fácil de corrigir uma vez que o desenvolvedor só precisa colocar restrições sobre os tipos de entrada que podem ser aceitos pela aplicação. Por exemplo, o desenvolvedor pode ter certeza de que apenas dados numéricos e certas frases são permitidas.

Cross-Site Scripting

Outro tipo de ataque contra um servidor web é o ataque cross-site scripting (XSS). Ele depende de uma variação do ataque de validação de entrada, mas o alvo é diferente porque o objetivo é ir atrás de um usuário em vez do aplicativo ou dados. Um exemplo de XSS usa métodos de script para executar um cavalo de Tróia com o navegador de um alvo. Isso seria feito possível através do uso de linguagens de script como JavaScript ou VBScript. Através de uma análise cuidadosa, um invasor pode procurar maneiras de injetar código malicioso em páginas da web, a fim de obter informações que vão desde informações de sessão no navegador, acesso privilegiado ao conteúdo no navegador.

Vejamos etapas do XSS em ação:

• O atacante descobre que um site sofre de um defeito de script XSS.
• Um atacante envia um e-mail informando que a vítima acaba de receber um prêmio e deve coletá-lo clicando em um link no e-mail. O link no e-mail vai para: http://www.badsite.com/default.asp?name=<script>badgoal()</ script>
• Quando o link é clicado, o site exibe a mensagem “Bem-vindo de volta!” Com um prompt para o usuário digitar seu nome.
• O site lê o nome de seu navegador através do link no e-mail. Quando o usuário clica no link no e-mail, o site é informado que seu nome é <script>evilScript</script>
• O servidor web relata o nome e o retorna ao navegador da vítima.
• O navegador interpreta corretamente isso como um script e executa o script.
• Este script instrui o navegador a enviar um cookie contendo algumas informações para o sistema do invasor, o que ele faz.

XSS é um ataque antigo e vários navegadores modernos incluem proteção contra isso. No entanto, a proteção não é infalível, e os ataques podem ser induzidos por má configuração, gambiarras ou mesmo add-ons de terceiros. Isso nem mesmo inclui ataques de script XSS que se originam do próprio servidor.

Redirecionamentos e encaminhamentos não validados

Para que esse tipo de ataque ocorra, a aplicação ou página da Web deve ter validação de entrada fraca ou inexistente.

Para visualizar este tipo de ataque, imagine que um site tem um módulo redirect.php que leva uma URL através de um parâmetro GET. A manipulação deste parâmetro pode criar uma URL no sitealvo.com que redireciona o navegador para sitedohackermaldoso.com. Quando o usuário vê o link, eles vão ver favorito.com/blahblahblah , que o usuário acha que é confiável e seguro clicar. Na realidade, o link irá enviá-los para uma página diferente, que neste caso pode fazer o download de software ou algum outro material malicioso no sistema de uma vítima.

Sistemas de logon inseguros

Muitos aplicativos da Web exigem algum tipo de autenticação ou processo de login antes usar. Devido à importância do processo de logon, é essencial que ele seja manuseado com segurança. Você deve tomar cuidado para que a entrada incorreta ou imprópria de informações não revele dados que um invasor pode usar para obter informações adicionais sobre um sistema.

Os aplicativos podem rastrear informações relacionadas a logons incorretos ou logins de usuários, se assim estiverem ativados. Normalmente, esta informação vem em forma de log, com lista de itens como estes:

• Entrada de um ID de usuário inválido com uma senha válida;
• Entrada de um ID de usuário válido com uma senha inválida;
• Entrada de um ID de usuário e senha inválidos;

Os aplicativos devem ser projetados para retornar informações genéricas que não revelem informações como nomes de usuários corretos. Os aplicativos da Web que retornam uma mensagem como “nome de usuário inválido” ou “senha inválida” podem dar a um invasor um alvo para se concentrar – como uma senha correta.

Erros de script

Aplicativos da Web, programas e código, como Common Gateway Interface (CGI), ASP.NET e JavaServer Pages (JSP) são comumente usados ??em aplicativos da Web e apresentam seus próprios problemas. Vulnerabilidades como a falta de scripts de validação de entrada podem ser um problema. Um atacante experiente pode usar uma série de métodos para causar tristeza ao administrador de um aplicativo da Web, incluindo o seguinte:

• Upload Bombing – Carrega massas de arquivos para um servidor com o objetivo de encher o disco rígido no servidor. Uma vez preenchido o disco rígido do servidor, a aplicação deixará de funcionar e vai falhar.
• Ataque Poison Null Byte – Este ataque passa caracteres especiais que o scripts não foram projetados para manipular corretamente. Quando isso é feito, o script pode conceder acesso onde não deveria ser dado.
• Scripts padrão – Os scripts padrão são frequentemente carregados em servidores por web designers que não sabem o que eles fazem em detalhes. Nesses casos, um intruso pode analisar ou explorar problemas de configuração com os scripts e obter acesso não autorizado a um sistema.
• Scripts de exemplo – Os aplicativos da Web podem incluir conteúdo de exemplo e scripts que estão regularmente em servidores. Em tais situações, esses scripts podem ser usados ??por um atacante.
• Scripts mal escritos ou questionáveis – Alguns scripts apareceram que incluem Informações como nomes de usuários e senhas, permitindo que um invasor visualize o conteúdo do script e leia essas credenciais.

Problemas de gerenciamento de sessão

Uma sessão representa a conexão que um cliente tem com o aplicativo do servidor. A informação da sessão que é mantida entre o cliente e o servidor é importante e pode dar a um invasor acesso a informações confidenciais, caso seja comprometida.

De forma ideal, uma sessão terá um identificador exclusivo, criptografia e outros parâmetros atribuídos sempre que uma nova conexão entre um cliente e um servidor for criada. Depois que a sessão for encerrada, fechada ou não for necessária, a informação será descartada e não será usada novamente (ou pelo menos não será usada por um período prolongado), mas isso nem sempre é o caso. Algumas vulnerabilidades desse tipo incluem o seguinte:

• Sessões de longa duração – As sessões entre um cliente e um servidor devem permanecer válidas apenas pelo tempo que eles são necessários e depois descartados. Sessões que permanecem válidas por períodos mais longos do que são necessárias permitem que intrusos usem ataques como XSS recuperem identificadores de sessão e reutilizem uma sessão.
• Recursos de Logout – Os aplicativos devem fornecer um recurso de logout que permite que um visitante faça logout e feche uma sessão sem fechar o navegador.
• Identificadores de sessão inseguros ou IDs de sessão facilmente previsíveis ou previsíveis – Algumas falhas em aplicativos da Web podem levar à reutilização de IDs de sessão. A exploração de IDs de sessão também pode cair na categoria de sequestro de sessão (session hijacking).
• Concedendo IDs de Sessão a Usuários Não Autorizados – Às vezes, os aplicativos concedem IDs de sessão para usuários não autenticados e redirecionam para uma página de logout. Isso pode dar ao invasor a capacidade de solicitar URLs válidos.
• Pobre ou Nenhum Controle de Mudança de Senha – Uma implementação inadequada ou insegura no sistema de alteração de senha, em que a senha antiga não é necessária, permite que um hacker altere senhas de outros usuários.
• Inclusão de informações desprotegidas nos cookies – Os cookies podem conter informações desprotegidas como o endereço IP interno de um servidor que pode ser usado por um hacker para saber mais sobre a natureza da aplicação web.

Protegendo Cookies

Como os cookies são parte integrante de aplicativos da Web, é importante compreender os métodos que podem ser usados ??para protegê-los adequadamente. Enquanto o desenvolvedor de um aplicativo é, em última instância, a única pessoa que pode fazer alterações para proteger os cookies na maioria dos casos, é importante entender o que eles podem fazer.

Já discutimos o que são os cookies e falamos um pouco sobre o que eles são usados ??e como eles podem ser comprometidos. Agora vamos falar sobre a definição de atributos que podem proteger os cookies e torná-los mais seguros.

A seguir está uma lista dos atributos que podem ser definidos em uma base por cookie, o que os torna mais seguros para usar:

• Secure – Quando esse atributo é definido em um cookie, informa ao navegador que os cookies só poderão ser enviados através de métodos seguros, como HTTPS. No entanto, no caso de uma aplicação web que utiliza HTTP e HTTPS, o cookie pode inadvertidamente ser passado em texto claro.
• HttpOnly – Definir este atributo defende contra ataques XSS porque o cookie só pode ser acessado via HTTP e não via scripts, como o JavaScript do lado do cliente. Pode não ser suportado em todos os navegadores.
• Domain – Quando esse atributo é usado, ele verifica se o domínio que o cookie está sendo usado é dele mesmo. Então um segundo atributo conhecido como o atributo path será verificado.
• Path – Quando o atributo de domínio é definido, o caminho pode então especificar se o local ou cookie é realmente válido. É importante ao usar esse atributo que você use o caminho mais restritivo possível para evitar ataques lançados de aplicativos co-localizados.
• Expires – Este atributo oferece uma forte proteção contra o mau uso de cookies porque ele realmente exclui o cookie quando a data de validade é excedida. No entanto, até que a data seja excedida, o cookie continuará a ser acessível e utilizado pela sessão do browser atual e todas as sessões seguintes. Se o atributo não estiver definido especificamente, o cookie será excluído assim que a sessão atual do navegador seja fechada.

Fraquezas na criptografia

Em aplicações web, criptografia desempenha um papel vital porque informações confidenciais são frequentemente trocadas entre o cliente e servidor na forma de logons ou outros tipos de informações.

Ao proteger aplicativos da Web, você deve considerar a segurança da informação em duas etapas: quando ela é armazenada e quando é transmitida. Ambas as etapas são áreas potenciais para o ataque. Ao considerar a criptografia e seu impacto na aplicação, concentre-se nesses áreas:

• Cifras fracas – Cifras fracas ou algoritmos de codificação são aqueles que usam chaves curtas ou são mal concebidas e implementadas. O uso de cifras fracas pode permitir que um invasor descriptografe dados facilmente e obtenha acesso não autorizado às informações. É importante que você nunca subestime o valor dos dados sendo armazenados, processados ??ou transmitidos pela sua aplicação web. Considere os dados que você armazena para seus clientes e como protegê-los. Informações confidenciais, como dados de cartão de crédito, nunca devem ser transmitidas. Se este tipo de informação precisa ser armazenado, use sempre a criptografia mais forte possível ou exigida, como AES 256 ou RSA 2048. Se ele não precisa ser armazenado, não armazene. Se você precisar processar pagamentos que envolverão esses dados, use um processador de pagamento que seja compatível com PCI para que você não precise assumir essa tarefa.
• Software Vulnerável – Algumas implementações de software que criptografam a transmissão dos dados, como Secure Sockets Layer (SSL), podem sofrer de programação deficiente e, portanto, tornar-se vulnerável a ataques como buffer overflow.

Algumas ferramentas e recursos estão disponíveis para ajudar na avaliação da segurança de aplicativos da Web e suas estratégias de criptografia associadas:

• OpenSSL, um toolkit de código aberto usado para implementar os protocolos SSLv3 e TLS v1: www.openssl.org
• O guia OWASP para falhas criptográficas comuns: www.owasp.org
• Nessus Vulnerability Scanner, que pode listar as cifras em uso por um servidor web: www.nessus.org
• WinSSLMiM, que pode ser usado para executar um ataque man-in-the-middle HTTPS: www.securiteinfo.com/outils/WinSSLMiM.shtml
• Stunnel, um programa que permite a criptografia de protocolos não-SSL-aware: www.stunnel.org

Ataque Directory Traversal

Este ataque também é conhecido como Path Traversal, ou traduzido ao pé da letra como ataque de passagem de diretório. Ele permite que um invasor se mova para fora do diretório do servidor web e para outras partes do host. Uma vez fora deste diretório, o invasor pode então ser capaz de ignorar permissões e outros controles de segurança e executar comandos no sistema.

Para executar este ataque, um intruso tira proveito de erros ou fraquezas em uma das duas áreas:

• As listas de controle de acesso (ACLs), que são usadas para indicar quais usuários e grupos têm permissão para acessar arquivos e diretórios em um servidor, bem como o nível de interação permitido;
• Diretório raiz, que é o diretório no servidor para o qual os usuários são especificamente restritos. Normalmente, esta é a pasta de nível mais alto que se pode chegar. O diretório raiz atua como o diretório superior do site e impede que os usuários obtenham acesso a arquivos confidenciais no servidor.

Para realizar um ataque de passagem de diretório, é surpreendentemente necessário pouco conhecimento e um navegador da Web. Com essas ferramentas e paciência, é possível encontrar cegamente arquivos e diretórios padrões em um sistema.

O sucesso do ataque depende em grande parte da configuração do site e do servidor, mas existem alguns tópicos comuns. Normalmente, os atacantes dependem de assumir ou falsificar-se como usuários e obter acesso a tudo o que os usuários têm acesso.

Nos aplicativos da Web com páginas dinâmicas (como PHP, ASP ou ASP.NET), a entrada é normalmente recebida dos navegadores por meio dos métodos de solicitação GET ou POST. Aqui está um exemplo de um URL de solicitação GET HTTP:

http://subdominio.nomedositealvo.com/pagina.asp?ver=conteudo.html

Com essa URL, o navegador solicita a página dinâmica pagina.asp do servidor e com ela também envia a exibição de parâmetros com o valor conteudo.html. Quando esta solicitação é executada no servidor web, pagina.asp recupera o arquivo conteudo.html do sistema de arquivos do servidor e o devolve ao solicitante. Através de algumas análises, um invasor pode assumir que a página pagina.asp pode recuperar arquivos do sistema de arquivos e criar um URL personalizada:

http://subdominio.nomedositealvo.com/pagina.asp?ver=../../../../../Windows/system.ini

Isso fará com que a página dinâmica recupere o arquivo system.ini do sistema de arquivos e exibe-o para o usuário. A expressão ../ instrui o sistema a ir um diretório para cima, que é comumente usado como uma diretiva de sistema operacional. O atacante tem que adivinhar quantos diretórios tem que ir até encontrar a pasta do Windows no sistema, mas isso é feito facilmente por tentativa e erro.

A estrutura do diretório real variará dependendo do próprio servidor, portanto este processo pode exigir uma quantidade considerável de tentativa e erro. Entretanto, considere o fato de que não é incomum que o software seja instalado em pastas e estruturas padrões.

Você não precisa usar o código para atacar o servidor. Você pode usar apenas o navegador sozinho. Um servidor web pode estar completamente aberto a um ataque de diretório de passagem e apenas à espera de um invasor ambicioso para rastrear e usar arquivos de exemplo e scripts contra ele.

Por exemplo, uma solicitação de URL que faz uso do diretório de scripts do IIS para percorrer diretórios e executar um comando pode ter esta aparência:

http://servidoralvoparaserinvadido.com/scripts/..%5c../Windows/System32/cmd.exe?/C+dir+c:\

A solicitação retorna uma lista de todos os arquivos no diretório C:\, executando o arquivo de shell do comando cmd.exe e executando o comando dir c:\ no shell. A expressão %5c que está na solicitação de URL é um código de escape do servidor web usado para representar caractere normal. Nesse caso, %5c representa o caractere \. Em alguns textos e whitepapers, o uso de um sinal % em um URL é conhecido como codificação percentual.

A maioria dos servidores web modernos verifica a presença de códigos e bloqueiam de serem usados. No entanto, com um número tão grande de servidores web de todos os tipos, é mais do que possível que o servidor que você escolher para atacar não irá filtrar esses códigos.

Protegendo-se de ataques Directory Traversal

Alguns métodos pode ser usado para impedir ataques deste tipo, como:

• Excutar software de servidor web modernos ou garantindo que patches atualizados estejam instalados;
• Ativando filtragem de entrada do usuário para o servidor web. É comum que servidores web modernos incluam a capacidade de filtrar solicitações ou códigos não padronizados.

Testando Aplicações Web

Como as aplicações web são complexas, pode ser necessário o uso de software especializado para analisar ou testar um aplicativo. Alguns destes pacotes de software estão aqui.

Burp Suite

O Burp Suite é um aplicativo baseado em Java usado para testar e atacar aplicativos da web. Em uma inspeção mais próxima o software é realmente uma coleção das ferramentas usadas para verificar diversas peças e características de uma aplicação.

O Burp Suite oferece uma combinação robusta de ferramentas que podem ser usadas tanto manual quanto automaticamente para verificar a aplicação. As ferramentas podem enumerar, analisar, verificar, atacar e explorar furos na aplicação web.

O Burp Suite inclui ferramentas que podem executar o seguinte:

• Proxy – A função proxy permite ao usuário encaminhar o tráfego entre o navegador e configurando o navegador da Web para usar o Burp Suite como um proxy. Quando em uso, o software permite a interceptação, visualização e alteração do tráfego entre o navegador e o servidor.
• Spider – Esta ferramenta pode mapear uma aplicação web, gerando um inventário da estrutura da aplicação.
• Scanner – Quando colocado em uso, o scanner pode descobrir vulnerabilidades em um aplicativo da Web. Em muitos casos, não é tão robusto como um scanner de vulnerabilidades dedicado, mas ainda é eficaz.
• Intruder – Esta é uma ferramenta de ataque automatizada e totalmente personalizável para aplicações web.
• Repeater – Esta é uma ferramenta para modificar e reeditar manualmente solicitações HTTP individuais e analisar a resposta de cada um.
• Sequencer – Este recurso específico é muito útil para testar aplicações web para susceptibilidade ao sequestro de sessão, inspecionando tokens para aleatoriedade.

Vega Web Application Scanner

Incluído com o Kali Linux 2.0 é um scanner projetado para avaliar uma aplicação web. O Vega é capaz de detectar problemas de injeção de SQL, XSS, divulgação de informações confidenciais e muito mais. Enquanto ele está presente e instalado no Kali Linux, ele está disponível no Windows e OS X também porque é baseado em Java.

Sugestões de livros: