< Insights

Como garantir a segurança no desenvolvimento de software?

  • Desenvolvimento de Software

A segurança no desenvolvimento de software causa diversos impactos, 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 da informação, o papel que vem à cabeça é o de infra-estrutura. Não estamos errados em pensar desta forma, mas será que 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 a 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!!”

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

Já estamos em um momento que não sabemos como vamos sofrer o ataque, e sim quando vamos sofrer o ataque. Devemos ter a visão 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, já 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.

Como melhorar a segurança no desenvolvimento de software?

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.

lista dos dez maiores riscos em sistemas

Figura 1: comparativo do OWASP entre os anos de 2013 e 2017 no top 10 de riscos a sistemas

Segurança com as senhas em sistemas

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ários ou máquina.

O ponto que deve ser levado em consideração após isso é a 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 a senha, ao adicionar este texto a senha o mesmo dificulta sua descoberta. A figura abaixo apresenta um exemplo desses sites:

exemplo de um salt

Figura 2: site crack hash com uma senha sem salt.

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 faz 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 pelo bem e pelo mal é o Metasploit.

print da tela do programa Metasploit

Figura 3: site do Metasploit e a facilidade de se obter.

Tratamento de erro como segurança para o software

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, elas geralmente tem algo com “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.

print de um site com informações sigilosas da população

Figura 4: exemplo de falha ao tratar erro.

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 isto ajude a abrir os olhos para a segurança no desenvolvimento de softwares. Caso precise de ajuda para garantir entregas de valor e seguras em softwares, fale agora mesmo com um de nossos especialistas!

Sugira um artigo

    Para enviar o formulário é necessário o aceite das políticas.

    Insights do nosso time

    Obtenha insights do nosso time de especialistas sobre metodologias de desenvolvimento de software, linguagens, tecnologia e muito mais para apoiar o seu time na operação e estratégia de negócio.