Hack this!

Fiquei sabendo à pouco de um novo site com propósitos didáticos para hacking ético. Ao que tudo indica, ele se parece com uma versão on-line do WebGoat da Owasp.

Confira no link:

http://www.hackthis.co.uk/

Privacidade - Scientific American

A edição de setembro da revista Scientific American (aqui) veio toda dedicada à privacidade que, segundo Esther Dyson, vai além de questões de segurança, saúde e intimidade. São considerados os seguintes assuntos:

• Definição e uso do termo privacidade.
• Legislação para escuta no âmbito do governo.
• Melhoria da saúde a partir do prontuário eletrônico e registros genéticos.
• Proteção contra roubo de identidade via autorização biométrica.
• Aparato para monitoramento.
• Chips de radiofreqüência (RFID).
• Vírus e outras pestes na Internet.

Aproveitem!

Análise do Mercado de Software Seguro

Para os que se interessam pelos números do mercado de segurança diretamente associados à questão do software, vale a pena apreciar a análise sobre os resultados de 2007, consolidados por McGraw (aqui).

Um breve resumo:

Ferramentas

• O mercado de ferramentas quase se dobrou, chegando a $150 – 180 milhões. No que tange à ferramentas de black box ocorreu uma estabilização. Neste segmento pequenas empresas tiveram um crescimento mais acentuado (Cenzic 16% e WhiteHat 52%). Já o mercado de análise de código chegou a $91,9 Milhões. Nesta lista encontram-se Fortify (83% - $29.2 Milhões), Klocwork (60% - $26 Milhões), Coverity (50% - $27.2 Milhões) e Ounce Labs (300% $9.5 Milhões).

Serviços

• Quanto a services, o crescimento foi mais modesto, apenas 20%. Treinamento (cerca de $7 Milhões), avaliação de riscos ($45-60 Milhões) e teste de penetração ($50-75 Milhões).

Microsoft Patch Tuesday Antecipada

A Microsoft começará a divulgar antecipadamente à parceiros da área de segurança, como fornecedores de anti-vírus, detalhes técnicos sobre a vulnerabilidade corrigida por ela.

Desde modo, a corrida para levantar tais informações diminuirá a dependência da engenharia reversa, iniciada logo após a divulgação dos patches de segurança na segunda terça-feira do mês, e permitirá que os fornecedores consigam provêr as atualizações de suas ferramentas de proteção com maior agilidade.

Detalhes no blog do Brian Krebs (aqui).

WebGoat versão 5.2

Acaba de ser lançada a nova versão 5.2 do WebGoat. Os interessados podem encontrar mais detalhes aqui.

A versão 5.1 traduzida para pt-br continua disponível aqui.

Quem se anima a traduzir mais esta versão para o português?

Entendendo XSS, XSRF e outros

Para alguns a compreensão sobre como um determinado ataque funciona se mostra como um reflexo, tamanha a intimidade deles com o conhecimento técnico associado. Para outros, a grande maioria, tal entendimento fica muito prejudicado pela defasagem técnica e, principalmente, pela maneira como tal informação é apresentada. Para este último, o designer gráfico exerce um papel determinante, articulando entre formas, cores e ações encadeadas de maneira a transformar uma informação que textualmente mostra se complicada, em algo de compreensão bastante facilitada. Com esta percepção o pesquisador Michael Schumacher da Virtual Forge criou um conjunto de animações para auxiliá-lo no treinamento de segurança de software. Aprecie o resultado e até compreenda problemas como XSS, XSRF e navegação forçada no blog da Justice League (aqui).

Google Libera Código Fonte do RatProxy

Acaba de ser liberado pela Google o código fonte da ferramenta RatProxy. Esta é uma das ferramentas usadas pela Google para teste de suas aplicações Web. Fica aí mais uma alternativa ao WebScarab da OWASP.

Mais detalhes sobre a ferramenta:

http://googleonlinesecurity.blogspot.com/2008/07/meet-ratproxy-our-passive-web-security.html

http://code.google.com/p/ratproxy/

Microsoft Source Code Analyzer for SQL Injection

Acaba de ser lançada pelo time de segurança do Microsoft SQL Server uma ferramenta de análise de código fonte especializada em encontrar falhas de injeção SQL em código ASP. Mais detalhes no SQL Server Security blog.

Utilidade Pública - Furo no Flash Player

Várias organizações de segurança de TI (aqui, aqui, aqui) têm divulgado advertências sobre a grave ameaça provocada pelo furo de segurança (estouro de buffer) encontrado no Flash em abril passado. Já existe registro de sites que usam essa vulnerabilidade para instalar software de captura de senhas nas máquinas com navegadores que usam a versão com o furo (aqui).

Antes de duvidar, proteja-se! É simples. Verifique a versão do Flash Player (aqui) e caso seja diferente de 9.0.124.0, faça a atualização (aqui).

WebGoat 5.1 em Português

No último final de semana consegui finalmente terminar a tradução do WebGoat 5.1 (Versão em Inglês). Foram 4 meses aproveitando o tempo de saguão de aeroporto, o próprio vôo, além daquelas situações onde a cabeça só aceita uma atividade mecânica. Foram cerca de 14o arquivos (vide imagem) distribuídos dentre plano da lição, dicas e soluções.

Para quem não conhece, o WebGoat é um site que coleciona um conjunto de páginas com vulnerabilidades divididas por algumas categorias, cujo intuito é de ensinar na prática qual o risco de desenvolver aplicações sem o compromisso com a segurança. Cada página possui um objetivo de ataque específico, descrito pelo plano da lição. Outros elementos, como por exemplo, as dicas permitem que o público adquira gradativamente os conhecimentos necessários para a efetivação de ataque a aplicações web.

Essa iniciativa vem a somar ao trabalho empenhado pela OWASP no sentido de divulgar informações sobre o desenvolvimento de aplicações com segurança. No que tange ao capítulo Brasil, soma-se as ações de tradução dos documentos para o português brasileiro. Tenho observado por onde passo, que ainda é muito grande a ignorância sobre a questão da segurança no desenvolvimento, e essa iniciativa procura diminuir uma das barreiras, o idioma.

Faça o download da versão de instalação aqui. Em breve tudo estará consolidado na página do WebGoat mantida pelo coordenador desse projeto, Bruce Mayhew.

O Impacto do PCI no Mercado

Para quem não conhece o PCI (Payment Card Industry) Standard, como o nome sugere é um padrão que a indústria que processa informações de cartões de crédito é obrigada a seguir. O padrão está organizado em 12 seções em um documento de 16 páginas (aqui). Para efeito da segurança de software, os itens seguintes são os mais relevantes:

6.5 Desenvolva todos os aplicativos de web baseados em diretrizes de codificação seguras tais como as diretrizes do Open Web Application Security Project. Revise o código dos aplicativos customizados para identificar as vulnerabilidades do código. Verifique a prevenção das vulnerabilidades mais comuns no processo de desenvolvimento dos códigos dos softwares para
incluir o seguinte:

6.5.1 Input não validado
6.5.2 Quebra do controle de acesso (por exemplo, uso desonesto dos IDs dos usuários)
6.5.3 Quebra da administração de autenticação/sessão (uso das credenciais da conta e
cookies da sessão)
6.5.4 Ataques ao cross-site scripting (XSS)
6.5.5 Overflow do buffer
6.5.6 Defeitos de injection (por exemplo, structured query language injection (SQL)
6.5.7 Administração incorreta dos erros
6.5.8 Armazenagem insegura
6.5.9 Recusa de serviço
6.5.10 Administração de configuração insegura.

6.6 Assegurar-se de que todos os aplicativos que funcionam por meio da web estejam protegidos
contra ataques conhecidos através dos seguintes métodos:
• Ter todos os códigos de aplicativos customizados revisados para vulnerabilidades comuns através de uma organização que se especialize em segurança de aplicativo
• Instalar uma camada de aplicativos (application layer) de firewall na frente dos aplicativos voltados para a web
Nota: Este método é considerado uma melhor prática até 30 de junho de 2008, e depois dessa data se tornará uma exigência.

Apesar da gama de preocupações abordada pelo modelo, o ponto de maior impacto neste momento vem na nota de duas linhas no final da seção 6.6. Pois a partir de junho próximo, toda entidade que ofereça software que trabalhe com informação de cartões será obrigada a utilizar as ferramentas especificadas por essa seção. Até agora o resultado mais evidente é a luta dos fornecedores para colocar seu produto no mercado (A Cicso é a última), ou se aliar com diferentes fornecedores para tentar oferecer a melhor solução (aqui). É provável que o resultado que mais nos interessa (software seguro) seja uma consequência natural disso e que outros negócios sejam influenciados pelos resultados dessa obrigação imposta pelo PCI. Veremos!

Terceirização de Software Seguro

É comum encontrar o cenário onde o contratante e o contratado em uma relação de terceirização nunca ouviram falar em software seguro e isso reflete diretamente nos aspectos legais entre as partes. Porém, algumas organizações já se encontram preocupadas sobre como estabelecer parâmetros legais que façam com que o negócio considere oficialmente a segurança no desenvolvimento, e permita às partes se comprometerem de fato.
Navegando pelo site da OWASP encontrei uma sugestão de minuta de contrato (aqui) que pode ser fonte de inspiração para as empresas que desejarem incorporar em seus contratos esse tipo de obrigação.

(In)Secure Magazine - Abril - 2008

A revista eletrônica, (In)Secure magazine de Abril traz um artigo que muito interessante sobre o desenvolvimento seguro "Producing Secure Software With Software Security Enhanced Processes" elaborado por Marco Morana. O artigo, além de discorrer sobre a abordagem mais defendida hoje para tratar do desenvolvimento de software seguro (segurança desde o princípio, faz ainda uma comparação muito rica sobre as propostas de segurança em processo mais difundidas hoje: MS-SDL, CLASP, Pontos de controle da Cigital.
Vale observar que a revista possui vários outros artigos relacionados a segurança. Vale a pena conferir.

O Que Esperar Fortify Souce Code Analyzer?

No final de março, tive a oportunidade de fazer o curso de auditor de código fonte com o Fortify Source Code Analyzer oferecido pela própria Fortify. O curso foi realizado em Denver no Colorado. A cidade, além de ser muito charmosa, fica bem próximo de Aspen. Foi uma pena não ter tido mais tempo para aproveitar esse outro lado.

Voltando ao curso em si, a turma era formada por oito pessoas. Todos inexperientes com a ferramenta. A maioria com experiência em desenvolvimento e em segurança no geral. Vale ressaltar que a Systest foi a empresa com mais participantes, quatro pessoas. O curso foi ministrado por Su Gaustad, cujo conhecimento acerca de desenvolvimento seguro e do uso do Fortify SCA impressiona, sua habilidade para lidar com o público também.

O Fortify SCA é um analisador estático de código fonte, cuja inteligência se resume nas regras desenvolvidas pela Fortify para encontrar furos de codificação, distribuídas dentre as seguintes abordagens de análise:

• Estrutural - Detecta uso de funções e APIs potencialmente perigosas.
  
• Semântica - Detecta furos potencialmente danosos na estrutura ou definição do programa. Por exemplo, uma atribuição de variáveis em Servlets, uso de loggers que não são declarados como static final.
  
• Fluxo de Controle - Detecta sequência de operações potencialmente perigosas. Isso remete à visualização análise de sequência de execução das operações, para verificar se alguma delas a aplicação é exposta a vulnerabilidades. Ex. Abrir uma conexão com banco de dados e não fechá-la, pode expor a aplicação à uma sobrecarga por não alocação de recursos.
  
• Fluxo de Dados - Detecta potenciais vulnerabilidades relacionadas a dados de entrada em processamento no software. Isso pressupõe uma análise inter-procedural, o que significa que suas regras são capazes reconhecem falhas de um dado recebido por um método, que é passado para outro método e lá sim, que ele oferece risco de se tornar uma vulnerabilidade explorável. Ex. Parâmetro de nome de arquivo recebido por um método é passado como parâmetro para outro método, que faz uso de strcopy para copiar o conteúdo de tal parâmetro para um buffer.
  
• Configuração - Localiza erros, pontos frágeis e violação de políticas nos arquivos de implantação da aplicação. Por exemplo, a connectionstring com parâmetros de usuário e senha no Web.Config em aplicações ASP.NET.
• Agrega a análise do FindBugs.
  

Seu processo de análise é organizado em três fases complementares:

• Tradução - onde o código fonte é recolhido segundo uma série de comandos e traduzido em um formato intermediário, que é associado à um BuildID (identificador do projeto em análise).
• Análise - compreende a busca por vulnerabilidades e análise de acordo com as regras descritas anteriormente.
• Verificação - garantia de que a análise foi realizada de acordo com as regras e seu resultado informa erros significativos.
  

Suporta as linguagens comercialmente mais utilizadas (Java, .NET, PHP, ColdFusion, JavaScript, PL-SQL), integra-se com as principais IDEs (Eclipse, Visual Studio 2003/05), como foi desenvolvido em Java, funciona em toda plataforma que suporte a JVM. É facilmente integrada com o ANT também.

Suas regras de análise (rulepack) são propriedade intelectual da Fortify e estão debaixo de forte critptografia. Seu acesso é dependente da manutenção da assinatura anual pelo seu uso. O que significa que, além da licença, é necessária a assinatura para usar o rulepack. Apesar de altamente não recomendado, a ferramenta permite ainda que sejam elaboradas regras próprias para as análises. Prepare-se pois a tarefa é de alta complexidade. Daí a razão da Fortify se disponibilizar a customizá-las, tão logo a necessidade seja indentificada pelos seus clientes, e devolver no rulepack.

Pela consistência dos resultados apresentados pelas análises (falso positivo/negativo) usando o SCA ao longo do curso, pela forma didática como ela os apresenta, bem como as facilidades proporcionadas para o auditor, percebo que essa ferramenta tem espaço garantido quando se tratar de ciclo de desenvolvimento seguro. Infelizmente, não conheço os detalhes do principal concorrente Ounce 5, para poder compará-las e desconheço também qualquer detalhe sobre os custos associados à sua arquisição/manuteção (pergunte à LeadComm), mas tenho a impressão que seu mercado é bem restrito.

Software Seguro sob a Perspectiva de Negócio

Desenvolver software seguro pressupõe um investimento adicional ao já oneroso ciclo de desenvolvimento de software. Essa realidade faz com que os executivos tradicionais tentem ignorar esse assunto o quanto podem. Esse "até quando podem" se traduz em perdas econômicas causadas por processos judiciais relativos à quebra de confidencialidade e outras violações, degradação da imagem, perda de mercado, etc.

O investimento em segurança no desenvolvimento é uma viagem obrigatória, com apenas estação partida, que toda organização, cujo negócio é software, se ainda não entrou, terá que entrar. Essa obrigatoriedade está diretamente ligada à curva crescente de perdas causadas por exploração de falhas de segurança.

Essa viagem está obviamente muito mais avançada nos EUA e países, cujo rigor com questões de segurança é maior. No Brasil, por exemplo, a onda de busca de soluções de segurança para atenter o padrão PCI (Payment Card Industry), mais especificamente o item 6, parece ainda nem ter começado. E veja você, que o uso de algumas alternativas para segurança no ciclo de desenvolvimento, como análise estática de código, firewall de aplicação sairão do status de recomendação no PCI para obrigatório em julho/08.

O mercado americano mostra boas perpectivas acerca dessa mudança de mentalidade, basta observar os movimentos das empresas, como por exemplo, a integração entre Sentinel (scan) da WhiteHat com o Ounce 5 (source code analyzer) da Ounce Labs e outros. Obviamente, eles estão prevendo alta demanda à caminho.

Voltando à questão do negócio em si, hoje as organizações (pelo menos as grandes) já reconhecem a importância de desenvolver software com segurança desde o princípio, e que o custo dessa alternativa é, sem dúvida, menor que os custos associdos à incerteza sobre o nível de segurança do produto final. Essa percepção sobre o nível de segurança é diretamente influenciada pelas evidências de ações de segurança recolhidas ao longo do desenvolvimento. Cita-se, como exemplo, os touch points da Cigital.

Não há outro elemento mais importante na segurança do que o recurso humano, quer seja no desenvolvimento ou na operação. Acontece, que as instituições de ensino em geral, continuam a não dar tanta importância ao assunto de software seguro. Quem paga a conta está começando a agir para mitigar esse problema. Como? Solicitando oficialmente às universidades para que ensinem seus alunos como desenvolver com segurança.

Para finalizar, fica destacado que a segurança no desenvolvimento não deve ser o objetivo de negócio de nenhuma organização (exceto àquelas onde esse é o negócio em si), mas que seu resultado pode suportar ou não os objetivos de negócio dela. Com essa mentalidade, a resistência a embarcar dessa viagem passa a ser dirigida pela análise de risco e custo da oportunidade.

--

Vale a pena assistir o podcast do McGraw com Mary Ann Davidson, CSO da Oracle.

RUP + Ounce 5. Será que emplaca?

Como era de se esperar as empresas já começam a se mobilizar para oferecer soluções de segurança para o desenvolvimento de software seguro. Quando digo soluções, me refiro ao uso integrado do ferramental disponível para habilitar de fato o desenvolvimento de software seguro.
A IBM e a Ounce Labs estão trabalhando em conjunto para que o RUP incorpore a abordagem de desenvolvimento de código seguro amparado por ferramenta de análise estática, o Ounce 5.

Particularmente, vejo duas alternativas para que as organizações comecem de fato a investir na segurança de software ao longo de seu ciclo de desenvovimento. A primeira via decreto (PCI, HIPAA), ou se enquadra ou "pede pra sair". A segunda é a partir do surgimento de propostas que facilitem a absorção da mudança causada por um ciclo de desenvolvimento que pressupõe segurança. Porque isso é determinante na análise de risco (de negócio) na hora de considerar tal alternativa.

Jogada de mestre. O processo mais usado se integrar com umas das ferramentas de análise estática mais usadas. Vamos ver se emplaca!

Como farei o curso de auditor pela Forify na semana do dia 23 de março, acredito ter mais informações sobre como ela se coloca diante desse cenário.

Para mais informação sobre análise estática para segurança sugiro o livro do Brian Chess: Secure Programming with Static Analysis.

Estratégia de Segurança que Funciona para a Web

Fiz a tradução do interessante post do Jeremiah Grossman, no qual ele dá uma visão geral da segurança em aplicações web e as alterativas corrente para lidar com esse problema.

Dentro de uma empresa vive um profissional de segurança de TI responsável pela segurança de sites web. Ele precisa levar seu trabalho muito à sério, sob a pena de receber uma ligação tarde da noite de seu chefe, caso o site de sua empresa seja atacado. Uma boa parte do trabalho requer educação dos desenvolvedores acerca da importância de codificação segura e reporte aos proprietários do negócio sobre os riscos relativos à segurança Web. Ele precisa fazer isso, pois nenhuma quantidade de patching ou firewalling conseguirá frear um atacante com um browser. Mesmo que use tudo que esteja em seu poder, ainda existe uma total falta de controle na proteção dos sites sob sua responsabilidade. Ele não pode corrigir as vulnerabilidades em website(s) quando elas são identificadas sem o envolvimento do desenvolvedor.

Essa situação lhe soa familiar? Eu ouço essa frustração à todo momento. O problema é que quando uma vulnerabilidade é identificada, quer seja pelo pen-tester, desenvolvedor, outsider ou quem quer que seja essas são as sofridas opções:

1. Parar o site.
2. Reverter para uma versão anterior do site/código (caso seja segura).
3. Continuar a funcionar apesar da exposição.

Nada é melhor que não ter um problema, mas vulnerabilidades aparecerão independente do ciclo de desenvolvimento de software. A opção #1 é tipicamente reservada para ocasiões onde um incidente tenha ocorrido e a opção 2# quando uma atualização do produto não possa ser devolvida para o desenvolvimento, que futuramente venha a ser sobrescrita. Até agora a história mostra que a grande maioria escolhe a opção #3 e assume o risco, ao invés de parar o negócio com atualizações.

É claro que são necessárias mais opções – algo que permita a mitigação de vulnerabilidades sem provocar impacto na operação do negócio.

Isto é importante, pois 9 entre 10 (ou mais) sites web possuem vulnerabilidades como resultado de serem produzidos por aqueles que não sabiam ou experimentaram a severidade dos ataques de hoje. Adicionalmente, eu poderia dizer que a maioria dos sites de comércio eletrônico populares foram desenvolvidos ou antes do descobrimento de vulnerabilidades prevalentes como o XSS, injeção SQL, CSRF, etc. ou antes deles se tornarem conhecidos. Consequentemente, estamos vulneráveis por 15 anos de códigos inseguro de sites em circulação e é pouco provável que esse código seja reescrito somente por “razões de segurança”. Ao longo da próxima década sua substituição acontecerá naturalmente de forma a atender os objetivos de negócio enquanto se aproveitando das tecnologias emergentes e frameworks mais seguros.

O que significa que quando você realiza uma análise honesta acerca da segurança do website, você terá duas estratégias de segurança possíveis:

1. Segurança ao longo do SDLC (ciclo de vida de desenvolvimento de software)
2. Avaliação de vulnerabilidade + WAF (Firewall de Aplicação Web)
   

A estratégia #1 se aplica mais à sites a serem construídos ou que estejam em fase de redefinição. Um programa de segurança Web combinando patrocínio executivo, frameworks modernos de desenvolvimento, treinamento de conscientização e segurança considerada no design e QA (garantia de qualidade) funciona. Por outro lado, esta estratégia é sempre difícil e cara para se implementar em sites existentes onde nenhuma atividade semelhante foi realizada anteriormente. Mesmo depois das vulnerabilidades identificadas é consome-se tempo a alocação de pessoal, QA / testes de regressão da correção e agendamento de versões de produção. Independente da maturidade do SDLC, isto demanda pelo menos dias, em alguns casos meses e mesmo meses para as falhas serem corrigidas. Este é o cenário mais comum hoje. O que tornará a conformidade com o PCI 6.6 (Payment Card Industry) um grande desafio, quando ela entrar em vigor.

Está é a razão pela qual a estratégia #2 é mais apropriada para websites existentes. A integração tecnológica demandada pela avaliação de vulnerabilidades é imediatamente importada para um WAF, criando uma “atualização virtual”. A integração fecha o ciclo entre identificação e mitigação de vulnerabilidade habilitando a oportunidade de endereçar as causa raízes assim que o tempo e o orçamento permitir. O desafio aqui é caso a fonte de dados seja imprecisa, de forma que a atualização virtual possa causar o WAF rejeitar trafego válido, permitir tráfego malicioso ou interromper inteiramente. Com dados verificados, a empresa é capaz de realizar por completo seu investimento de avaliação de vulnerabilidade em tempo real, confiando no modo de bloqueio do WAF e fornecendo aos profissionais de TI o controle até agora ausente. E isto é relativo ao tempo também!

Caso essa solução lhe soar familiar, pode ser pelo fato dessa idéia ter sido usado no passado, nunca em segurança de aplicações web. Kavado tentou na era 2002-2003, em 2003-2004 muitos outros fornecedores tentaram usar o AVDL e estou certo que tiveram outros, mas ultimamente todas as tentativas se comprovaram falíveis, devido às razões mencionadas anteriormente. Só recentemente que a tecnologia de scanneamento de vulnerabilidades e WAP está se materializando e decisões de negócio necessitam ser realizadas, possuir uma variedade de opções disponíveis é algo muito muito bom.

A pescaria já não é mais a mesma de antigamente

Pescaria é uma tradição no Brasil. Quem nunca participou, certamente tem algum parente, amigo, vizinho que já foi e não vê a hora de repetir a experiência. A autêntica pescaria brasileira sugere s seguinte combinação: uma turma de amigos, sendo pelo menos um violeiro, muita bebida (vale qualquer tipo, mas a cerveja e a cachaça são fundamentais), a tralha de pesca (barco, vara, etc.) e um maço de dinheiro para, na falta da "sorte", não chegar em casa de mão abanando.

Apesar de ser esta a mais famosa para nós brasileiros, é outra pescaria que tem ganhado destaque na área de segurança mundo afora. Essa pescaria apesar de ser análoga à tradicional, não preserva seus elementos fundamentais. Aquele clima amistoso de diversão e confraternização já era! Até a bebida foi abandonada! O rio agora nem água tem mais, o que se vê é bit. O peixe agora corresponde à informação sigilosa espalhada nesse rio de bit, que vira dinheiro tão logo o "pescador" resolva apropriar-se de recuros financeiros espalhados pelos bancos que usam essa via, a partir do "peixe".

E nessa nova pescaria, referida amplamente como fishing, o Brasil vem recebendo internacionalmente mais reconhecimento que na tradicional! Duvida? Confira aqui.

SecBuemba! Nova técnica de medir qualidade de código revisado

Acaba de ser lançada uma nova técnica de medição da qualidade de código revisado, cuja efetividade nunca havia sido alcançada. Confira em detalhes a aplicação da WFT aqui.

A contribuição do Fuzzing para o Software Seguro

Já foi mencionado aqui técnicas para localizar vulnerabilidades, com uma rápida menção à técnica conhecida como Fuzzing. Tudo bem que o objetivo não era explicá-la em detalhes, mas considerar várias delas. Mas pelo papel determinante que vem ocupando no chão de fábrica do desenvolvimento de código seguro, ela merece mais destaque. Com essa mesma opinião, a revista eletrônica DarkReading nos fez o favor de publicar recentemente um artigo com detalhes sobre a técnica, com comparação entre ferramentas, além de apontar para outras fontes de pesquisa, como o blog Scott Lambert, do Microsoft’s Security Engineering Tools Team, e o livro que será lançado em maio "Fuzzing for Software Security: Robustness Testing for Quality Assurance and Vulnerability".
Para os mais anciosos, já existe um livro sobre o assunto, chamado "Fuzzing: Brute Force Vulnerability Discovery".

Acesso grátis aos livros da OWASP

A OWASP está disponibilizando alguns de seus livros para download sem custo (de graça). Duvida? Acesse aqui e aproveite. Para aqueles que resistem ao ebook, podem adquirir as versões impressas por um valor simbólico, que varia de 5 a 18 dólares.

Top 10 Vulnerabilities traduzido para o português

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!