Bom dia/tarde/noite pessoal, chegamos ao último drop sobre desenvolvimento seguro, hoje falaremos sobre:
Lidando com erros e logs
Saber lidar com erros é essencial para a segurança, quando um erro acontece e não é tratado ele pode deixar o software num estado vulnerável.
A solução é pegar cada erro em potencial e olhar para o código para garantir que quando um erro ocorra o programa não seja deixado em um estado vulnerável. Esse princípio é chamado de “falhar seguramente”. Isso significa que você deve pegar todas as exceções e checar todos os valores retornados, deve também desativar todos os recursos utilizados e diminuir privilégios. Em linguagens com exception handling é possível se beneficiar de construções try-catch-finally se forem suportadas.
Verificar se recursos ainda estão disponíveis é algo facilmente esquecível, como por exemplo, verificar se existe memória disponível ou se o disco está cheio (isso poderia evitar ataques de negação de serviço por exemplo).
Logging
Logs não são somente um jeito excelente de diagnosticar problemas, eles podem servir também como forma de detectar ataques em um sistema.
Que informação deve ser “logada”? Para responder essa questão (embora seja impossível fazer isso de maneira direta) você deve determinar que tipo de informação é necessária para detectar um ataque e possivelmente investigá-lo posteriormente.
Por exemplo, logs de tentativas de login mal sucedidas podem ajudar a detectar um ataque de força bruta para identificação da senha, mas não irá te dizer se o ataque foi ou não bem sucedido. Portanto, combinar com logs de logins bem sucedidos pode ser uma boa ideia. Cuidado com leis de privacidade (LGPD e outras) que podem gerar problemas se você gravar dados pessoais em logs. Evite dados pessoais e dados sensíveis como senhas, referencie usuários por ID (pseudonimização) e gere log de alterações importantes de configurações do sistema ou de acesso e alteração à dados pessoais.
Uma prática interessante é verificar regularmente se os logs não foram alterados em trânsito (Tampering), eles podem ser armazenados em mídias write-once ou read-many ou até mesmo terem checksums gerados para verificação.
Logs podem ser vistos por diversas ferramentas automatizadas, isso certamente pode ajudar, mas existe um risco, se existe uma ferramenta capaz de ver certa informação, essa também pode ser alvo de ataques de injeção se as entradas não forem validadas seguramente e se os privilégios não forem verificados.
Negação de serviço
Um ataque de negação de serviço (DoS) objetiva consumir quanto recurso do sistema conseguir até que ele fique indisponível. Sabemos que existem ataques de DDoS (distributed denial of service), onde vários atacantes, intencionais ou não (no caso de infectado por botnets, muito recorrente em dispositivos de IoT) fazem requisições a determinado servidor. Esse grande tráfego de informação deixa o servidor não responsivo. Outro exemplo seria fazer upload de arquivos enormes em um servidor web, criando várias contas de usuário ou adicionando vários itens a um carrinho de compras.
A melhor forma de reduzir esses ataques é limitar a quantidade de recursos que podem ser alocados. Por exemplo, permitir um número máximo de pedidos por compra. Em casos onde uma operação causa um grande consumo de recursos (como uma query complicada) impor esse tipo de limite pode ser difícil. Em casos assim teremos que ser criativos para achar uma solução.
Algo mais difícil ainda de mitigar que os ataques de negação de serviço são sistemas que deixam a si mesmos indisponíveis. Por exemplo, travar um usuário depois de 3 tentativas de login sem sucesso. Um atacante poderia abusar disso para deixar o sistema indisponível para os usuários. Não existe forma correta de mitigação aqui, o melhor a se fazer é achar uma solução que se adapta bem a cada caso.
Continuando o estudo
Bom pessoal, chegamos ao final da nossa jornada sobre desenvolvimento seguro. Isso foi uma abordagem bem rápida sobre o tema, porém bem relevante como passo inicial, já que existe bem mais a ser explorado nessa área.
Existem frameworks inteiros sobre desenvolvimento seguro: https://securesoftwarealliance.org/ e também certificações que podem ser obtidas
https://www.exin.com/qualification-program/exin-secure-programming
https://www.isc2.org/Certifications/CSSLP
https://cert.eccouncil.org/ec-council-certified-secure-programmer.html
Fica então o convite para que vocês possam dar continuidade com esse aprendizado e se tiverem interesse, quem sabe podemos elaborar um grupo de estudo apenas para explorar esse tema, preparar para certificações ou escalar o debate e ver como podemos nos beneficiar disso para nosso ciclo de desenvolvimento. Muito obrigado a todos que se interessaram e uma ótima semana.
