A segurança causa diversos impactos no desenvolvimento de software – desde a sua performance (que pode ser comprometida caso não seja elaborada corretamente), até a sua qualidade.

Um software pensado e criado de forma segura, além de garantir sua disponibilidade, apresenta uma alta satisfação e a confiança ao cliente que seus dados estão preservados. Portanto, precisamos conhecer alguns pontos de melhoria para incluir no desenvolvimento de nossos sistemas.

Geralmente, quando pensamos em segurança de informação, o papel que vem à cabeça é o de infra-estrutura. Não estamos errados em pensar desta forma, mas cabe somente a eles a preocupação com a segurança?

Hoje organizações têm tido mais e mais gastos com medidas de segurança reativas do que preventivas.

Ao pensar em uma solução para um sistema, a performance e a regra de negócio estão em caminhos opostos à segurança na maior parte do tempo, seja por falta de conhecimento dos recursos envolvidos, custos altíssimos ou simplesmente por uma resposta instantânea.

É neste ponto que vemos algumas gafes de segurança como:

• – “Não, não precisa criptografar a senha aqui. Está na rede do cliente”

Ou:

• – “Ninguém vai tentar fazer esse acesso aqui, com certeza!”

Estes infelizmente são pensamentos errados ao apresentar uma alternativa para os problemas.

Já estamos em um momento em que não sabemos como vamos sofrer o ataque, e sim quando vamos sofrer o ataque. Devemos ter a visão de que sempre quem ataca detém a vantagem sobre quem defende.

A grosso modo, o atacante sempre vai ter artifícios diferentes para entrar em nosso sistema ou coletar dados, porém, quem defende não pode deixar estes artifícios obterem sucesso.

Um único erro de quem defende é o bastante para que todo o resto dos gastos com segurança seja quase insignificante. Por este motivo existem algumas dicas básicas para melhorar a segurança na criação e manutenção dos nossos sistemas.

• Formas de melhoria de segurança em aplicações
• Sanitizar ou filtrar entradas

Nada mais é do que tomar o cuidado de limpar ou filtrar apenas o necessário ao sistema. Ao permitir a utilização de qualquer entrada, estamos dando espaço a ataques de injeção de código malicioso.

O exemplo mais utilizado é o “Hello World!” de SQL injection (injeção de um código para consulta no banco de dados que retorna mais do que foi programado originalmente) que, ao obter sucesso, o atacante pode fazer o que bem quiser com o banco de dados.

Existem dois grandes obstáculos com soluções de sanitização: ser performático e cobrir todas as entradas.

Por isso, é muito custoso sua implementação na maioria das soluções – tanto em questão de valores quanto performaticamente.

Uma solução é filtrar somente o que precisa, o que na maioria das vezes é um tanto complicado de ser aplicado.

Para exemplificar, o OWASP (Projeto Aberto de Segurança em Aplicações Web) divulga uma lista dos dez maiores riscos em sistemas, e curiosamente o ataque de injeção está em primeiro lugar em todos os anos, como no comparativo entre os anos de 2013 e 2017.

Cuidado com as senhas

Uma forma de proteger tanto nossos usuários quanto nosso sistema é dificultar a entrada por força bruta (forma de ataque com várias tentativas em sequência que pode levar ao sucesso e a mais fácil de ser efetuada).

Portanto, não deixar o usuário cadastrar senhas como “123456” e “admin” ou qualquer senha fraca é uma forma de evitar este tipo de ataque.

Para assegurar mais ainda e evitar este tipo de ataque, o sistema ainda pode bloquear várias tentativas de um usuário ou máquina.

O ponto que deve ser levado em consideração após isso é à respeito do ataque de DoS (negação de serviços), que se for mal planejado o tratamento anterior, a consequência desse erro é que para o atacante fica mais fácil enviar várias requisições para o sistema e assim acontece a negação de serviço.

Senhas devem ser gravadas de forma irreversível

Vamos dizer que por um descuido deixamos passar alguma entrada maliciosa e permitimos qualquer senha no nosso sistema, ou, o pior de todos os casos: alguém descobre um Zero Day (nome dado a vulnerabilidades não conhecidas pelos desenvolvedores e consequentemente não corrigidas).

Imagine aquela senha “123456” em nosso banco de dados gravada em texto simples. Pois é, acabamos de entregar o acesso ao sistema sem a necessidade do atacante precisar quebrar alguma coisa e ser descoberto.

Por isso, devemos pensar em proteger essas senhas. Uma das formas que mais surte resultado é a utilização sempre da senha com um salt aleatório e gravado em forma de hash. Em resumo, adicionando um texto a senha que seja aleatório, e depois o mesmo deve utilizar criptografia unidirecional (não reversível).

O motivo da utilização de um salt é que temos sites com enormes bases de dados, onde uma busca simples pode levar à senha. Ao adicionar este texto à senha, o mesmo dificulta sua descoberta. A figura abaixo apresenta um exemplo desses sites:

Atualização contínua de sistemas

O processo de atualização de versão muitas vezes custa muito caro e talvez seja o principal motivo de organizações manterem ferramentas com versões desatualizadas e descontinuadas. Infelizmente isso abre um buraco muito grande para ataques.

O motivo é que existem programas que geram automaticamente códigos que fazem o ataque literalmente em um piscar de olhos e sem nenhuma dificuldade, se aproveitando daquilo que já foi um dia um Zero Day.

Um bom exemplo de programa muito utilizado para o bem e para o mal é o Metasploit.

Tratamento de erro

Deixar de tratar um erro pode ser uma complicação. Uma mensagem errada pode entregar a versão do sistema – assim entregamos qual ferramental está sendo utilizado e todas as vulnerabilidades conhecidas.

Um bom exemplo que temos são mensagens do banco de dados Oracle, que geralmente apresentam algo como “ORA-…”. Em resumo isso é “entregar o jogo” ao atacante.

Outro exemplo é o apresentado na Figura 4. O mesmo é referente a um site com informações sigilosas da população. Alguns dados foram escondidos por motivos de segurança, mas podemos observar que, além de entregar qual ferramenta está utilizando, ainda apresenta a versão. No caso, “Apache Tomcat” e versão 8.0.30.

São regras simples, mas que evitam algumas dores de cabeça, como acessos forçados, facilidade de execução de um ataque ou simplesmente a negação de um serviço.

Espero que isso ajude a abrir os olhos para o desenvolvimento seguro de nossos softwares, mas não tenha isso como única forma de solucionar os problemas descritos, nem como a melhor forma.

Um grande abraço e até a próxima!

***

Artigo original publicado no Objective e republicado com a autorização do autor: https://www.objective.com.br/seguranca-nossa-de-cada-dia-para-o-desenvolvimento-de-software/