Segurança nossa de cada dia para o desenvolvimento de software | iMasters
Segurança nossa de cada dia para o desenvolvimento de software
Tem 1 artigos publicados com 369 visualizações desde 2019
Desenvolvedor na Objective Solutions, Paulo Roberto Zanardo Junior é também especialista em Perícia Digital pela Universidade Católica de Brasília e entusiasta de segurança da informação.
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.
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?
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.
– "Não, não precisa criptografar a senha aqui. Está na rede do cliente"
– "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.
Formas de melhoria de segurança em aplicações
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.
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.
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.
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).
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:
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.
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.
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.
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/