Ferramenta para busca de problemas de segurança em aplicações WEB
Pessoal,
Esse assunto é de interesse de empresa que trabalha com desenvolvimento de aplicações WEB.
O motivo desse post é despertar o interesse em todos sobre esse assunto, e mostrar também os problemas comuns de segurança em aplicações WEB, para que dessa forma possamos sempre estar melhorando nossas aplicações.
Quando trabalhamos com aplicações WEB estamos expostos a tipos de ameaças (ataques) que não são tão simples de se identificar e que podem nos causar muitos problemas.
Alguns exemplos desses tipos de ameça são:
Ataques XSS e XSRF, SQL Injection e Insecure Direct Object Reference, e mais alguns que não vou citar para não estender muito o post.
XSS - Cross Site Scripting
Este tipo de falhas consiste em injetar código (normalmente JavaScript ou VBscript) no browser do usuário, alterando o código da página, podendo assim levar ao roubo de informações. Erros em validações de parâmetros enviados pelo método GET ou POST são o principal motor deste tipo de falha.
XSS também conhecido como CSS (Cross Site Scripting, facilmente confundido com Cascading Style Sheets) é uma vulnerabilidade muito comum encontrada em aplicativos web. XSS permite ao atacante inserir códigos maliciosos nessas páginas, para que sejam executados no momento em que tais páginas forem acessadas.
Os ataques XSS tiram partido das falhas na forma como um determinado site processa os conteúdos inseridos por um usuário em formulários, URLs e até mesmo nos cabeçalhos dos pedidos HTTP. Explorando esses erros na validação de conteúdos, um atacante pode introduzir Javascript malicioso no site.Quando o site atacado exibe essa informação a um usuário, o Javascript malicioso é executado no browser do usuário podendo assim ter a informações privilegiadas como Cookies por exemplo.
Em sites que utilizam apenas Cookies como meio de autenticação, um ataque XSS bem sucedido, permite a um atacante ganhar controle sob a identidade do usuário atacado.
Traduzindo, é possível por exemplo ter a informações de acesso de um usuário adminstrador de um sistema WEB se a aplicação for vulnerável a ataques XSS.
XSRF - Cross-Site Request Forgery
XSRF é a sigla para Cross Site Request Forgery. Esta técnica pode ser usada de várias formas e a vítima tem que estar autenticada na aplicação vulnerável.
Quando um usuário se autentica em uma aplicação web existe uma relação de confiança entre o usuário e a aplicação durante o período de tempo em que a sessão autenticada permanece ativa. Neste período a aplicação não solicita uma nova autenticação (usuário e senha) a cada função que o usuário acessa da aplicação. Existe aplicações que solicitam novamente a senha em algumas funções críticas, como é o caso de pagamentos de contas em aplicações de home banking. Mas a maioria das aplicações web autenticam o usuário apenas uma vez e confiam nesta autenticação até o fechamento do navegador ou a sessão cair por tempo de inatividade.
Para fazer um ataque de XSRF, o atacante tem que conhecer a aplicação alvo e identificar a url ou o formulário que realiza a função crítica, como por exemplo, aprovação de processo, enviar mensagem, confirmar uma pendência importante, etc.
O atacante estuda a função crítica, identifica o endereço das páginas e os parâmetros que são enviados.
De posse destas informações, o atacante monta um link ou um código HTML que irá executar a função crítica estudada.
Por exemplo, pode existir uma aplicação financeira que quando um usuário legítimo aprova um pagamento através de um botão, o botão na verdade ativa o endereço http://aplicacao/aprova_pagamento?id_conta=10.
Conhecendo o endereço, os parâmetros e a forma com uma função crítica é chamada, o atacante tem que fazer a vítima clicar no link enquanto ela está autenticada na aplicação. Existem várias formas de se conseguir isso:
Quando o usuário estiver autenticado na aplicação e clicar em um link ou acessar um página que tenha o script ou html com ataque de XSRF irá executar a função até mesmo sem saber.
No nosso exemplo a vítima poderá aprovar um pagamento sem intenção através da chamada a url http://aplicacao/aprova_pagamento?id_conta=10.
Qual o perigo?
Existe um risco muito grande principalmente em aplicações que usam o conceito web 2.0. Essas aplicações possuem conteúdo montado por usuários, compartilhamento de informações e grande interatividade com usuários. Aplicações corporativas com funções críticas também são alvos deste tipo de ataque.
SQL Injection
SQL Injection é das vulnerabilidades mais conhecidas (senão a mais conhecida) pela Internet.
SQL Injection ocorre quando o atacante consegue inserir uma série de intruções SQL dentro de uma 'query' através da manipulação das entrada de dados de um aplicação. Pequenos erros de validação podem se revelar catastróficos e extremamente embaraçantes.
O principal motivo pelo qual deve-se impossibilitar a utilização da SQL Injection está no fato de que, através de uma simples instrução SQL, como por exemplo, uma projeção de dados (consulta para exibir alguma informação na aplicação web - um relatório), outras operações podem ser executadas, podendo impactar sobre o esquema das tabelas , os dados armazenados, etc.
Qual o perigo?
Perder todas as informações de um determinado banco de dados/tabela. Isso já é motivo mais que suficiente para se preocupar com esse tipo de ataque.
Existe algumas ferramentas para busca de problemas de segurança em aplicações WEB, muitas delas caras e dificeis de usar.
Mais por felicidade o Google tem uma ferramenta para busca de problemas de segurança em aplicação WEB que se chama RatProxy¹ que foi desenvolvida em seus laboratórios.
É um software desenvolvido pelo Google para testar suas aplicações e que seu código fonte está disponivel sobre a licença Apache 2.0.
Isso o Google usa o RatProxy¹ para testar suas aplicações WEB :)
Por que não usar o RatProxy¹ para testar nossas soluções então ?
Vou tentar descrever como o software funciona bem por cima, sem entrar em detalhes muito técnico.
Após realizar o download da aplicação basta um comando para fazer a instalação, e já está pronto para se utilizar a ferramenta.
Ele trabalha com um proxy, você roda a aplicação passando qual é o dominio (endereço da aplicação) que deseja fazer os testes, depois configura seu navegador para utilizar o RatProxy¹.
Após essa etapa o que precisa ser feito é utilizar a aplicação WEB normalmente.
Ele trabalha no meio da aplicação WEB, toda informação que é trocada pele seu navegador e a aplicação WEB é analisada pelo RatProxy.
O RatProxy gera um log com as informações dos possiveis problemas encontrados na aplicação WEB, no final é possivel gerar um relatório em html das vulnerabilidades encontradas. É legal que nesse relatório ele mostra o que pode estar errado no codígo da aplicação :-)
O RatProxy mostra os possiveis problemas, mas temos que fazer a avaliação, portanto não adianta o RatProxy nos alertar sobre um potencial risco de XSS se não conhecemos o que é o problema e como resolve-lo.
Reforçando a idéia desse post é despertar o interesse pelo assunto, e que possamos evoluir no estudo de segurança das nossa aplicações WEB.
[1] - Link para ferramenta RatProxy: http://code.google.com/p/ratproxy/
Esse assunto é de interesse de empresa que trabalha com desenvolvimento de aplicações WEB.
O motivo desse post é despertar o interesse em todos sobre esse assunto, e mostrar também os problemas comuns de segurança em aplicações WEB, para que dessa forma possamos sempre estar melhorando nossas aplicações.
Quando trabalhamos com aplicações WEB estamos expostos a tipos de ameaças (ataques) que não são tão simples de se identificar e que podem nos causar muitos problemas.
Alguns exemplos desses tipos de ameça são:
Ataques XSS e XSRF, SQL Injection e Insecure Direct Object Reference, e mais alguns que não vou citar para não estender muito o post.
XSS - Cross Site Scripting
Este tipo de falhas consiste em injetar código (normalmente JavaScript ou VBscript) no browser do usuário, alterando o código da página, podendo assim levar ao roubo de informações. Erros em validações de parâmetros enviados pelo método GET ou POST são o principal motor deste tipo de falha.
XSS também conhecido como CSS (Cross Site Scripting, facilmente confundido com Cascading Style Sheets) é uma vulnerabilidade muito comum encontrada em aplicativos web. XSS permite ao atacante inserir códigos maliciosos nessas páginas, para que sejam executados no momento em que tais páginas forem acessadas.
Os ataques XSS tiram partido das falhas na forma como um determinado site processa os conteúdos inseridos por um usuário em formulários, URLs e até mesmo nos cabeçalhos dos pedidos HTTP. Explorando esses erros na validação de conteúdos, um atacante pode introduzir Javascript malicioso no site.Quando o site atacado exibe essa informação a um usuário, o Javascript malicioso é executado no browser do usuário podendo assim ter a informações privilegiadas como Cookies por exemplo.
Em sites que utilizam apenas Cookies como meio de autenticação, um ataque XSS bem sucedido, permite a um atacante ganhar controle sob a identidade do usuário atacado.
Traduzindo, é possível por exemplo ter a informações de acesso de um usuário adminstrador de um sistema WEB se a aplicação for vulnerável a ataques XSS.
XSRF - Cross-Site Request Forgery
XSRF é a sigla para Cross Site Request Forgery. Esta técnica pode ser usada de várias formas e a vítima tem que estar autenticada na aplicação vulnerável.
Quando um usuário se autentica em uma aplicação web existe uma relação de confiança entre o usuário e a aplicação durante o período de tempo em que a sessão autenticada permanece ativa. Neste período a aplicação não solicita uma nova autenticação (usuário e senha) a cada função que o usuário acessa da aplicação. Existe aplicações que solicitam novamente a senha em algumas funções críticas, como é o caso de pagamentos de contas em aplicações de home banking. Mas a maioria das aplicações web autenticam o usuário apenas uma vez e confiam nesta autenticação até o fechamento do navegador ou a sessão cair por tempo de inatividade.
Para fazer um ataque de XSRF, o atacante tem que conhecer a aplicação alvo e identificar a url ou o formulário que realiza a função crítica, como por exemplo, aprovação de processo, enviar mensagem, confirmar uma pendência importante, etc.
O atacante estuda a função crítica, identifica o endereço das páginas e os parâmetros que são enviados.
De posse destas informações, o atacante monta um link ou um código HTML que irá executar a função crítica estudada.
Por exemplo, pode existir uma aplicação financeira que quando um usuário legítimo aprova um pagamento através de um botão, o botão na verdade ativa o endereço http://aplicacao/aprova_pagamento?id_conta=10.
Conhecendo o endereço, os parâmetros e a forma com uma função crítica é chamada, o atacante tem que fazer a vítima clicar no link enquanto ela está autenticada na aplicação. Existem várias formas de se conseguir isso:
* Gravar um script ou html numa aplicação vulnerável a Cross Site Scripting. Quando o usuário autenticado acessar o script ou html gravado irá processar e executar a função da aplicação sem saber;
* Se aplicação permitir a edição de figuras, o atacante poderá incluir uma figura que execute uma url;
* Colocar um link em outra aplicação e solicitar para um usuário autenticado clicar no link ou acessar uma página que tenha o script ou o link montado especialmente para o XSRF.
Quando o usuário estiver autenticado na aplicação e clicar em um link ou acessar um página que tenha o script ou html com ataque de XSRF irá executar a função até mesmo sem saber.
No nosso exemplo a vítima poderá aprovar um pagamento sem intenção através da chamada a url http://aplicacao/aprova_pagamento?id_conta=10.
Qual o perigo?
Existe um risco muito grande principalmente em aplicações que usam o conceito web 2.0. Essas aplicações possuem conteúdo montado por usuários, compartilhamento de informações e grande interatividade com usuários. Aplicações corporativas com funções críticas também são alvos deste tipo de ataque.
SQL Injection
SQL Injection é das vulnerabilidades mais conhecidas (senão a mais conhecida) pela Internet.
SQL Injection ocorre quando o atacante consegue inserir uma série de intruções SQL dentro de uma 'query' através da manipulação das entrada de dados de um aplicação. Pequenos erros de validação podem se revelar catastróficos e extremamente embaraçantes.
O principal motivo pelo qual deve-se impossibilitar a utilização da SQL Injection está no fato de que, através de uma simples instrução SQL, como por exemplo, uma projeção de dados (consulta para exibir alguma informação na aplicação web - um relatório), outras operações podem ser executadas, podendo impactar sobre o esquema das tabelas , os dados armazenados, etc.
Qual o perigo?
Perder todas as informações de um determinado banco de dados/tabela. Isso já é motivo mais que suficiente para se preocupar com esse tipo de ataque.
Existe algumas ferramentas para busca de problemas de segurança em aplicações WEB, muitas delas caras e dificeis de usar.
Mais por felicidade o Google tem uma ferramenta para busca de problemas de segurança em aplicação WEB que se chama RatProxy¹ que foi desenvolvida em seus laboratórios.
É um software desenvolvido pelo Google para testar suas aplicações e que seu código fonte está disponivel sobre a licença Apache 2.0.
Isso o Google usa o RatProxy¹ para testar suas aplicações WEB :)
Por que não usar o RatProxy¹ para testar nossas soluções então ?
Vou tentar descrever como o software funciona bem por cima, sem entrar em detalhes muito técnico.
Após realizar o download da aplicação basta um comando para fazer a instalação, e já está pronto para se utilizar a ferramenta.
Ele trabalha com um proxy, você roda a aplicação passando qual é o dominio (endereço da aplicação) que deseja fazer os testes, depois configura seu navegador para utilizar o RatProxy¹.
Após essa etapa o que precisa ser feito é utilizar a aplicação WEB normalmente.
Ele trabalha no meio da aplicação WEB, toda informação que é trocada pele seu navegador e a aplicação WEB é analisada pelo RatProxy.
O RatProxy gera um log com as informações dos possiveis problemas encontrados na aplicação WEB, no final é possivel gerar um relatório em html das vulnerabilidades encontradas. É legal que nesse relatório ele mostra o que pode estar errado no codígo da aplicação :-)
O RatProxy mostra os possiveis problemas, mas temos que fazer a avaliação, portanto não adianta o RatProxy nos alertar sobre um potencial risco de XSS se não conhecemos o que é o problema e como resolve-lo.
Reforçando a idéia desse post é despertar o interesse pelo assunto, e que possamos evoluir no estudo de segurança das nossa aplicações WEB.
[1] - Link para ferramenta RatProxy: http://code.google.com/p/ratproxy/
postado por Luciano Borguetti às
9:31 PM
|
1 Comentários
