Como você pode notar pelos artigos anteriores (confira a parte 7 neste link), a construção de um aplicativo seguro dá muito trabalho.

Um atalho para um software seguro pode ser tirar vantagem dos recursos de segurança do seu framework de aplicação. Frameworks como .NET, Rails, Play, Django e Yii fornecem muitas proteções de segurança incorporadas se você usá-las corretamente. Veja recursos como .NET Project e .NET Securuty Cheat Sheet da OWASP, guia de segurança do Ruby on Rails, guia de segurança do framework Play, documentação de segurança do Django, ou como escrever aplicativos Yii seguros, guia de códigos seguros da Apple ou guia de segurança do Android para desenvolvedores para as melhores práticas de segurança específicas do framework e diretrizes.

É provável que haja buracos no que a seu framework oferece, os quais você pode preencher usando bibliotecas de segurança como Apache Shiro, Spring Security, ou o abrangente (e pesado) ESAPI da OWASP. Há também as bibliotecas para fins especiais, como Jasypt ou Google KeyCzar e Legion of the Bouncy Castle para criptografia, e as que codificam para proteção XSS e proteção a outros tipos de injeção.

Mantenha os frameworks e as bibliotecas atualizados

Se você for usar o código de outra pessoa, tenha a certeza de mantê-lo atualizado. No último ano, os problemas de alta prioridade, incluindo uma onda de vulnerabilidades graves no Rails em 2013 e o recente bug Heartbleed no OpenSSL, deixaram bem claro o quanto é importante conhecer todos os frameworks de código aberto e as bibliotecas que você usa em seu aplicativo (incluindo na pilha de tempo de execução), e ter certeza de que esse código não possui vulnerabilidades sérias conhecidas.

Nós já sabemos há algum tempo que os componentes populares de softwares de código aberto também são alvos de ataques populares (e fáceis) para os bandidos. E nós estamos facilitando a vida deles.

Um estudo de 2012 realizado por Aspect Security e Sonatype analisou 113 milhões de downloads dos frameworks Java mais populares (incluindo Spring, Apache CXF, Hibernate, Apache Commons, Struts e Struts2, GWT, JSF, Tapestry e Velocity) e bibliotecas de segurança (incluindo Apache Shiro, Jasypt, ESAPI, BouncyCastle e AntiSammy). Eles descobriram que 37% desses softwares continham vulnerabilidades conhecidas, e que as pessoas continuaram baixando versões obsoletas do software com vulnerabilidades conhecidas mais de ¼ do tempo.

Isso se tornou um problema muito comum e grave o suficiente para que o uso de frameworks de software e outros componentes com vulnerabilidades conhecidas agora apareça na lista dos Top 10 de risco OWASP.

Encontre código com vulnerabilidades conhecidas e corrija-o – fácil, certo?

Você pode usar uma ferramenta como verificação de dependência livre do OWASP ou ferramentas comerciais como Sonatype CLM para manter o controle de componentes de código aberto em seus repositórios e identificar o código que contém vulnerabilidades conhecidas.

Depois de encontrar os problemas, você tem que resolvê-los – e corrigi-los rapidamente. Uma pesquisa feita por White Hat Securuty mostra que as vulnerabilidades de segurança graves na maioria dos aplicativos Java levam uma média de 91 dias para consertar quando uma vulnerabilidade é encontrada. Isso está deixando a porta aberta por muito tempo, quase que garantindo que caras maus encontrarão o seu caminho. Se não assumir a responsabilidade por este código, você pode acabar tornando o aplicativo menos seguro, em vez de mais seguro.

No próximo artigo, vamos voltar ao começo e dar uma olhada na segurança nos requisitos.

***

Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em http://swreflections.blogspot.com.br/2014/07/10-things-you-can-do-as-developer-to.html