Desenvolvimento

26 set, 2014

10 boas práticas para tornar seus aplicativos mais seguros – Parte 10

Publicidade

Há muito mais para garantir design e arquitetura, além da implementação correta da autenticação, controle de acesso e estratégias de registro e escolha de (e corretamente usando) um bom framework.

Você precisa considerar e lidar com ameaças à segurança e riscos em vários pontos diferentes em seu design.

O novo livro de Adam Shostack sobre modelagem de ameaças explora, em detalhes, como fazer isso, com muitos exercícios e exemplos sobre como procurar e corrigir falhas de segurança no projeto de software e como pensar sobre os riscos do projeto.

Mas algumas ideias básicas importantes no projeto de segurança o levarão longe:

Conheça suas ferramentas

Ao decidir sobre a linguagem e a tecnologia que você usará no sistema, certifique-se de que você compreende as restrições de segurança e os riscos que suas escolhas acarretarão. Se você estiver usando uma nova linguagem, reserve um tempo para aprender sobre como escrever o código corretamente e com segurança nessa linguagem. Se você estiver programando em Java, C ou C++ ou Perl, confira as diretrizes de codificação seguras do CERT para essas linguagens. Caso esteja escrevendo código sobre iOS, leia o guia de codificação seguras da Apple. Para .NET, revise o projeto de segurança para .NET da OWASP.

Procure ferramentas de análise estática como Findbugs e PMD para Java, JSHint para JavaScript, OCLint para C/C++ e Objective-C, Brakeman para Ruby, RIPS para PHP, ferramentas de análise estática da Microsoft para a .NET, ou ferramentas comerciais que ajudarão na captura de bugs de segurança comuns e bugs de lógica na codificação ou integração contínua.

E certifique-se de que você (ou ops) entende como bloquear ou endurecer o O/S e configurar com segurança o seu gerente de contêiner e banco de dados (ou dados NoSQL).

Camadas e confiabilidade

Camadas e confiabilidade no design estão intimamente ligados. É preciso compreender e verificar a suposição de confiança nos limites de cada camada da arquitetura e entre sistemas e os componentes no design, a fim de decidir quais controles de segurança precisam de ser reforçados a esses limites: autenticação, controle de acesso, validação de dados e codificação, criptografia, registro.

Entenda quando os dados ou o controle cruzam um limite de confiabilidade: para/a partir do código que está fora do seu controle direto. Isso poderia ser um sistema de fora, um navegador, um cliente móvel ou outro tipo de cliente, ou outra camada da arquitetura ou outro componente ou serviço.

Pensar sobre a confiabilidade é muito mais simples e mais concreto do que pensar em ameaças. E mais fácil de testar e verificar. Basta fazer algumas perguntas simples:

De onde os dados estão vindo? Como você pode ter certeza? Você pode confiar neles – eles foram validados e codificados de forma segura? Por outro lado, você pode confiar no código para proteger a integridade e confidencialidade dos dados que você passa para ele? Você sabe o que acontece se uma exceção ou um erro ocorre – você pode perder dados ou a integridade deles ou pode ocorrer vazamento de dados, se o falha na abertura ou no fechamento?

Antes de fazer alterações no design, certifique-se de que você entende essas premissas e de que as hipóteses estão corretas.

A superfície de ataque do aplicativo

Finalmente, é importante entender e gerenciar a superfície de ataque do sistema: todos os caminhos que os atacantes podem usar, ou extrair dados do sistema, todos os recursos que estão expostos a ataques. APIs, arquivos, sockets, formulários, campos, URLs, parâmetros, cookies. E o esquema de segurança que protege essas partes do sistema.

Seu objetivo deve ser tentar manter a superfície de ataque a menor possível. Mas isso é muito mais fácil de falar do que de fazer: cada recurso e ponto de integração novos aumentam a superfície de ataque. Tente entender os riscos que você está introduzindo e como eles são sérios. Você está criando uma nova API de network-facing ou projetando um novo fluxo de trabalho de negócios que lida com dinheiro ou dados confidenciais, ou alterando o seu modelo de controle de acesso, ou trocando uma parte importante de sua arquitetura de plataforma? Ou você está só adicionando mais um formulário de administração CRUD, ou apenas mais um campo a um formulário ou arquivo existente? Em cada caso, você está alterando a superfície de ataque, mas os riscos serão muito diferentes, assim como a maneira que você vai gerenciar esses riscos.

Para mudanças pequenas e bem compreendidas, os riscos são geralmente insignificantes – apenas continue codificando. Caso os riscos sejam altos o suficiente, você vai precisar fazer análises de caso de abuso ou de modelagem de ameaça, ou reservar um tempo para uma revisão de código ou teste de invasão.

E, claro, uma vez que um recurso ou uma opção ou interface não é mais necessário, remova-o e apague o código. Isso vai reduzir a superfície de ataque do sistema, bem como simplificar a sua manutenção e os testes de trabalho.

É isso aí! Terminamos.

As 10 coisas que você pode fazer como um desenvolvedor para tornar o seu aplicativo seguro: pensar sobre segurança em camadas arquitetônicas e escolhas de tecnologia, incluir a segurança nos requisitos, aproveitar-se do código de outras pessoas utilizando frameworks e bibliotecas com cuidado, certificar-se de implementar controles básicos de segurança, recursos como autenticação e controle de acesso corretamente, proteger a privacidade dos dados, registrar com segurança, lidar com entrada de dados e parar os ataques de injeção, principalmente de injeção de SQL.

Esta lista não é exaustiva. Mas compreender e lidar com essas importantes questões na segurança de aplicativos – incluindo a segurança quando você pensa em requisitos, projeto, codificação e testes, sabendo mais sobre as suas ferramentas e usando-as adequadamente – é um trabalho que todos os desenvolvedores podem fazer, e será um longo caminho até tornarem seu sistema seguro e confiável.

***

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-to-as-developer-to.html