Com o intuito de facilitar o acesso à documentação sobre segurança no desenvolvimento fizemos a tradução do documento conhecido como Top 10 Vulnerabilities da OWASP. Ele concentra informações sobre as dez vulnerabilidades mais relevantes para as aplicações web, bem como alternativas combatê-las.
Aproveitem!
quinta-feira, 10 de janeiro de 2008
quinta-feira, 18 de outubro de 2007
Lições aprendidas em segurança pela Microsoft
A revista MSDS Magazine de novembro 2007 traz um artigo elaborado pelo Michael Howard, onde são compartilhadas 10 lições aprendidas pela Microsoft ao longo dos cinco anos de investimento em desenvolvimento de código seguro. Vale a pena conferir!
Lessons Learned from Five Years of Building More Secure Software
Lessons Learned from Five Years of Building More Secure Software
sexta-feira, 28 de setembro de 2007
Microsoft Guidance Explorer
Para os desenvolvedores .NET que não conhecem o Microsoft Guidance Explorer (versão Web) ainda, vale a pena analisá-lo. Ele aborda as recomendações de Patterns&Practices de uma perspectiva mais aplicada ainda.
Segue apenas algumas orientações de segurança tiradas dele para o desenho de software seguro, na plataforma .NET.
Segue apenas algumas orientações de segurança tiradas dele para o desenho de software seguro, na plataforma .NET.
- Partition your web site and secure restricted pages with ssl
- Protect authentication cookies
- How to use fxcop
sábado, 15 de setembro de 2007
Sugestão de Leitura "State of the Art of Software Security Assurance"
Copio o post do Cima, onde ele divulga o lançamento pelo DoD (US - Department of Defense) do relatório sobre o estado a arte em desenvolvimento de software seguro.
Segue o post - Dica: Relatório "State of the Art of Software Security Assurance".
Adicionalmente, sugiro outro relatório, este do DHS (Department of Homeland Security) produzido em agosto de 2006, mais conciso, mas tão denso quanto o do DoD, chamado Security in the Software LifeCycle.
Segue o post - Dica: Relatório "State of the Art of Software Security Assurance".
Adicionalmente, sugiro outro relatório, este do DHS (Department of Homeland Security) produzido em agosto de 2006, mais conciso, mas tão denso quanto o do DoD, chamado Security in the Software LifeCycle.
sexta-feira, 24 de agosto de 2007
Core Grasp for PHP
Foi lançada a ferramenta Core Grasp para PHP, cujo objetivo é detectar e bloquear a injeção de vulnerabilidades e violação de privacidade.
Quem desenvolve em PHP sabe das dificuldades de construir uma aplicação segura a partir desse framework. Vale a pena considerar....
Mais informações: CORE GRASP.
Quem desenvolve em PHP sabe das dificuldades de construir uma aplicação segura a partir desse framework. Vale a pena considerar....
Mais informações: CORE GRASP.
terça-feira, 14 de agosto de 2007
Afinal de contas, qual a melhor forma de encontrar vulnerabilidades?
Existem três abordagens básicas para descobrir vulnerabilidades: testes white box, black box e gray box. A diferença entre os três pode ser analisada pelo prisma dos recursos disponíveis para o testador. Em um extremo, temos o teste white box, cuja abordagem requer acesso completo a todos os recursos. Incluindo código fonte, desenho e até um conversa com o programador. No outro extremo encontra-se o teste black box, onde os recursos internos do sistema são indisponíveis. O teste de penetração é um exemplo dessa abordagem. Já os testes gray box não possuem uma definição bem estabelecida. Mas vamos combinar que para esse tipo, o testador tem acesso as bibliotecas compiladas e, em alguns casos, documentação básica.
Teste white box
Essa abordagem explora em profundidade o código fonte na tentativa de localizar falhas de segurança. A análise de código fonte pode ser realizada manualmente, impraticável em grande escala, e automatizada pelo uso de ferramentas de análise de código fonte.
Essa abordagem implica que seu conhecimento corresponde apenas aquilo que pode ser observável, assim como um usuário final. Assim como para o teste caixa branca, esta abordagem é realizada de maneira manual e automatizada, sendo esta conhecida como Fuzzing.
Este teste uso como recurso determinante o acesso ao binário da aplicação, sendo sua avaliação de segurança também conhecida como auditorida de binário. Assim como para as outras abordagens, esta é realizada manualmente ou com o uso de ferramenta. Vale ressaltar que o que pode não ser automatizado é a análise e não o desassembly.
Teste white box
Essa abordagem explora em profundidade o código fonte na tentativa de localizar falhas de segurança. A análise de código fonte pode ser realizada manualmente, impraticável em grande escala, e automatizada pelo uso de ferramentas de análise de código fonte.
Vantagens
- Cobertura - pelo fato do código fonte estar disponível, uma revisão de código permite sua cobertura total. Todos os fluxos de código podem ser auditados na busca de vulnerabilidades. Isto pode levar a falsos positvos, à medida que nem todos os fluxos sejam verificados.
- Complexidade - a análise dos resultados gerados pelas ferramentas é de muita complexidade, pois exigem uma revisão criteriosa de cada registro para verificar se realmente corresponde a uma vulnerabilidade.
- Disponibilidade - o código fonte nem sempre é um recurso disponível.
Essa abordagem implica que seu conhecimento corresponde apenas aquilo que pode ser observável, assim como um usuário final. Assim como para o teste caixa branca, esta abordagem é realizada de maneira manual e automatizada, sendo esta conhecida como Fuzzing.
Vantagens
- Disponibilidade - aplicáveis sempre, inclusive nas situações onde o código fonte esteja disponível.
- Reproducibiliade - pelo fato deste teste não levar em conta pressupostos sobre o alvo, a ação pode ser reproduzida para diversos sistemas.
- Simplicidade - mesmo que abordagens que usem engenharia reversa requeiram habiliades especializadas, o teste black box em seu nível básico pode ser conduzido sem um conhecimento interno denso da aplicação.
- Cobertura - um dos maiores desafios é saber quando parar os testes quão efetivo ele tem sido.
- Inteligência - o teste black box é mais indicado para cenários onde a vulnerabilidade é causada por vetor de ataque individual. Ataques complexos podem, entretanto, exigir múltiplos vetores de ataque e nesses casos é necessário um entendimento profundo da aplicação, possibilitado pelo acesos ao código fonte.
Este teste uso como recurso determinante o acesso ao binário da aplicação, sendo sua avaliação de segurança também conhecida como auditorida de binário. Assim como para as outras abordagens, esta é realizada manualmente ou com o uso de ferramenta. Vale ressaltar que o que pode não ser automatizado é a análise e não o desassembly.
Vantagens
- Disponibilidade - com exceção de aplicações web remotas, o binário está sempre disponível.
- Cobertura - informação obtida com esta análise pode ser utilizada na melhora da técnica black box.
- Complexidade - A engenharia reversa é uma habilidade especializada e consequentemente recursos podem não estar disponíveis para sua realização.
quinta-feira, 9 de agosto de 2007
The Securty Development Lifecycle book...
Para aqueles que tiverem interesse em um resumo breve do livro SDL, podem conferir a apresentação elaborada por mim durante a sua leitura.
Reforço, que vale a pena a leitura do livro, cujo conteúdo é bastante denso e sua leitura não é tão árida. O que o torna acessível a qualquer um com conhecimentos básicos da área de computação.
Reforço, que vale a pena a leitura do livro, cujo conteúdo é bastante denso e sua leitura não é tão árida. O que o torna acessível a qualquer um com conhecimentos básicos da área de computação.
Assinar:
Postagens (Atom)