Segurança no Design de Aplicativos
Por Augusto Alves
É crescente o número de notícias envolvendo incidentes de violação da segurança cibernética. O avanço tecnológico, principalmente com a aceleração das tecnologias pós pandemia construíram uma maior “superfície de ataque” para agentes maliciosos, e isso é um fator que precisa ser levado em consideração ao tratarmos de riscos. Sabemos das limitações que alguns têm com investimentos em tecnologia e principalmente em segurança, embora estes tenham sido impulsionados pela recém Lei Geral de Proteção de Dados, nem todos tiveram recursos para estruturar um plano de prevenção e respostas a incidentes de segurança da informação.
No entanto, é possível que desenvolvedores de serviços digitais e softwares adotem o conceito de “segurança por design”, gerando uma camada a mais de segurança e trazer mais confiabilidade para seu cliente, que poderá contar com mais segurança. Prevenir um sistema com falhas é algo que nós programadores podemos controlar. Escrever um software seguro é talvez o método mais efetivo de prevenir a maioria dos crimes digitais que existem hoje. (Devanbu & Stubblebine, 2000).
Um método que ajuda bastante é aplicar o acrônimo STRIDE (Hernan, Lambert, Ostwald, & Shostack, 2006), que descreve os tipos possíveis de ataques. Durante o ciclo de desenvolvimento é importante considerar esses termos em qualquer interação que o sistema faça.
Spoofing – Fingir ser alguém ou algo que você não é.
Tampering – Modificar dados armazenados ou em trânsito.
Repudiation – Negar que você fez ou não fez algo.
Information Disclosure – Ver uma informação que você não está autorizado a ver.
Denial-of-Service – Tornar um sistema ou funcionalidade indisponível.
Elevation of Privilege – Fazer algo sem permissão.
Uma forma eficiente de aprofundar-se em segurança de código é a utilização do OWASP Top 10. O OWASP Top 10 é um documento padrão de conscientização para desenvolvedores e segurança de aplicativos da web. Ele representa um amplo consenso sobre os riscos de segurança mais críticos para aplicativos da web. Globalmente reconhecido pelos desenvolvedores como o primeiro passo para uma codificação mais segura. Usar o OWASP Top 10 é talvez o primeiro passo mais eficaz para mudar a cultura de desenvolvimento de software em sua organização para uma que produza um código mais seguro. Em 2017 foi criado o rank dos 10 maiores riscos em aplicações.
TOP 10 Maiores Riscos de Segurança em Aplicações (OWASP TOP 10):
1 Injeção: Falhas de injeção, como SQL, NoSQL, OS e injeção de LDAP, ocorrem quando dados não confiáveis são enviados a um interpretador como parte de um comando ou consulta. Os dados hostis do invasor podem induzir o interpretador a executar comandos indesejados ou acessar dados sem a devida autorização. (Mais informações sobre como detectar essa vulnerabilidade e se proteger em: https://owasp.org/www-project-top-ten/2017/A1_2017-Injection )
2 Quebra de autenticação: as funções do aplicativo relacionadas à autenticação e gerenciamento de sessão são muitas vezes implementadas incorretamente, permitindo que os invasores comprometam senhas, chaves ou tokens de sessão ou explorem outras falhas de implementação para assumir as identidades de outros usuários temporária ou permanentemente. (Mais informações sobre como detectar essa vulnerabilidade e se proteger em: https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication )
3 Exposição de dados confidenciais: Muitos aplicativos da web e APIs não protegem adequadamente os dados confidenciais. Os invasores podem roubar ou modificar esses dados fracamente protegidos para conduzir fraude de cartão de crédito, roubo de identidade ou outros crimes. (Mais informações sobre como detectar essa vulnerabilidade e se proteger em: https://owasp.org/www-project-top-ten/2017/A3_2017-Sensitive_Data_Exposure )
4 XML Entidades externas (XXE): Os invasores podem explorar processadores XML vulneráveis se puderem fazer upload de XML ou incluir conteúdo hostil em um documento XML, explorando código vulnerável, dependências ou integrações. (Mais informações sobre como detectar essa vulnerabilidade e se proteger em: https://owasp.org/www-project-top-ten/2017/A4_2017-XML_External_Entities_(XXE )
5 Quebra de controles de acesso: As restrições sobre o que os usuários autenticados têm permissão para fazer muitas vezes não são aplicadas de forma adequada. Os invasores podem explorar essas falhas para acessar funcionalidades e / ou dados não autorizados. (Mais informações sobre como detectar essa vulnerabilidade e se proteger em: https://owasp.org/www-project-top-ten/2017/A5_2017-Broken_Access_Control )
6 Configuração incorreta de segurança: a configuração incorreta de segurança é o problema mais comum. Isso geralmente é o resultado de configurações padrão inseguras ou configurações incompletas como por exemplo, armazenamento em nuvem aberta, cabeçalhos HTTP configurados incorretamente e mensagens de erro detalhadas contendo informações confidenciais. Todos os sistemas operacionais, estruturas, bibliotecas e aplicativos devem ser configurados com segurança, e devem ser corrigidos / atualizados em tempo hábil. (Mais informações sobre como detectar essa vulnerabilidade e se proteger em: https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration )
7 Cross-Site Scripting XSS: As falhas de XSS ocorrem sempre que um aplicativo inclui dados não confiáveis em uma nova página da web sem validação. O XSS permite que os invasores executem scripts no navegador da vítima, que podem sequestrar as sessões do usuário, desfigurar sites ou redirecionar o usuário para sites maliciosos. (Mais informações sobre como detectar essa vulnerabilidade e se proteger em: https://owasp.org/www-project-top-ten/2017/A7_2017-Cross-Site_Scripting_(XSS) )
8 Desserialização insegura: A desserialização insegura geralmente leva à execução remota de código. Ainda assim, mesmo que as falhas de desserialização não resultem na execução remota de código, elas podem ser usadas para realizar ataques, incluindo ataques de repetição, ataques de injeção e ataques de escalonamento de privilégios. (Mais informações sobre como detectar essa vulnerabilidade e se proteger em: https://owasp.org/www-project-top-ten/2017/A8_2017-Insecure_Deserialization )
9 Usar componentes com vulnerabilidades conhecidas: Componentes, como bibliotecas, estruturas e outros módulos de software, são executados com os mesmos privilégios do aplicativo. Se um componente vulnerável for explorado, esse tipo de ataque pode facilitar a perda séria de dados ou o controle do servidor. Aplicativos e APIs que usam componentes com vulnerabilidades conhecidas podem minar as defesas do aplicativo e permitir vários ataques e impactos. (Mais informações sobre como detectar essa vulnerabilidade e se proteger em: https://owasp.org/www-project-top-ten/2017/A9_2017-Using_Components_with_Known_Vulnerabilities )
10 Registro (logs) e monitoramento insuficientes: Os invasores contam com a falta de monitoramento e ausência de respostas para incidentes para atingir seus objetivos sem serem detectados. A maioria dos estudos de violação mostra que o tempo para detectar uma violação é de mais de 200 dias, normalmente detectado por partes externas em vez de processos internos ou monitoramento. (Mais informações sobre como detectar essa vulnerabilidade e se proteger em:https://owasp.org/www-project-top-ten/2017/A10_2017-Insufficient_Logging%2526Monitoring )
Referências
Devanbu, P. T, & Stubblebine (2000) . Software engineering for security: a roadmap. In Proceedings of the Conference on the Future of Software Engineering. ACM.
Hernan, S., Lambert, S., Ostwald, T., & Shostack, A. (2006). Threat modeling – Uncover security design flaws using the STRIDE acronym. MSDN Magazine, 68-75.
https://owasp.org/www-project-top-ten/
