Com o objetivo de otimizar processos e promover o desenvolvimento corporativo, profissionais cada vez mais estão migrando para plataformas online. Segundo a VDC Research, 45% dos projetos embarcados envolvem o desenvolvimento de produtos terceirizados. Além disso, de acordo com a consultoria, o uso de open source terceirizado, software comercial, código-fonte legado e código binário aumenta a cada ano. Na mesma medida em que se trata de um cenário positivo para a entrega de soluções de qualidade e com rápido deploy, é imprescindível que haja a análise de segurança em bibliotecas de terceiros antes do seu uso.
O motivo é que os cibercriminosos vêm mudando seu foco de servidores e sistemas operacionais para aplicativos, pois, se não existe a correção de vulnerabilidades pelos desenvolvedores, este se torna um caminho fácil para o acesso a dados corporativos críticos e confidenciais. Isso inclui os softwares de terceiros que, muitas vezes, são utilizados pelas empresas.
Riscos que os softwares de terceiros podem trazer à uma organização
Além de observar a qualidade das plataformas online e os recursos que elas podem trazer para a operação, fazer uma análise de segurança em bibliotecas terceiras minimiza as chances de invasões às aplicações, ao mesmo tempo em que se aproveita o melhor que a tecnologia pode oferecer. Pensando nisso, listamos alguns dos principais riscos de utilizar materiais de terceiros:
- Exposição a Cross-Site Scripting (XSS), que acontece em função de falha na validação dos dados de entrada do usuário e a resposta do servidor web, abrindo brecha para a injeção de código malicioso;
- Estar sujeito a vetores de ataques Cross-Site Request Forgery (CSRF), também denominado XSRF, Sea Surf ou Session Riding, os quais permitem que o cibercriminoso realize inúmeras ações, como transferências de fundos, alterações de senhas, realização de compras até o comprometimento total da aplicação;
- Predisposição para truques de clickjacking que, traduzido, significa “furto de clique”. Esta ameaça é feita mediante o sequestro de iframes, banners e botões em páginas da web. Ao clicar nestes locais infectados, os usuários pensam estar acessando páginas inofensivas que, na realidade, são armadilhas. Como consequência pode haver, por exemplo, infecção por malwares, utilização de câmeras e microfones, phishing e ataques a dispositivos mobile;
- Falhas de injeção, em que um invasor pode usar campos de entrada de dados, como formulários, para injetar códigos maliciosos na aplicação, e outros ataques comuns.
Estes pontos não são tão diferentes de quando é utilizado código próprio, mas há riscos adicionais como perda de dados confidenciais e pessoais, acesso não autorizado a sistemas e outros aplicativos e tempo de inatividade da infraestrutura do sistema.
Melhores práticas para mitigar riscos
Para minimizar os riscos de introduzir vulnerabilidades nos aplicativos da web através da análise de segurança em bibliotecas de terceiros, é preciso configurar um processo estruturado no fluxo de desenvolvimento da empresa. Este processo é composto por algumas etapas.
Veja as principais:
-
Inventário de ativos
O primeiro passo é fazer um inventário de quais plataformas e códigos open source os aplicativos da web estão usando. Pense, por exemplo, na pasta de pacotes globais para soluções NET Core ou o equivalente para outras linguagens de programação e ambientes de desenvolvimento, os quais geralmente contêm muitos pacotes.
É possível que se tenha instalado alguns deles, mas, provavelmente, eles dependem de outros pacotes. Então, a aplicação acaba tendo uma quantidade significativa de códigos que não foram escritos no projeto. E quanto mais códigos não controlados houver, maior será a probabilidade de se introduzir vulnerabilidades no aplicativo.
Além disso, é importante considerar até mesmo os scripts ou folhas de estilo que se incluem nos aplicativos, independentemente de adicionar uma cópia empacotada deles ou um link para uma Content Delivery Network (CDN). Pense em ativos jQuery e Bootstrap ou na tag do Google Analytics, por exemplo.
Saber exatamente quais dependências o projeto de desenvolvimento usa é fundamental para conhecer os riscos associados e mitigá-los. Essa etapa também pode trazer a oportunidade de pensar sobre a necessidade real de cada solução de terceiros.
-
Análise de dependências
Depois de listar as bibliotecas de terceiros usadas no projeto, o próximo passo é inspecioná-las para procurar vulnerabilidades. Se ela vier de um projeto de open source, é possível verificar seu código. Caso contrário, a indicação é consultar os boletins de segurança do fornecedor ou verificar bancos de dados especializados, como o National Vulnerability Database.
Verificar manualmente todas as dependências, obviamente, não é viável. Mas é possível usar ferramentas que automatizam essa tarefa. Por exemplo, se você usa o GitHub como seu provedor de serviços de repositório de código, deve receber regularmente alertas de vulnerabilidades de segurança que podem afetar as dependências dos projetos.
Qualquer que seja a ferramenta usada, o resultado desta etapa de análise é uma lista das vulnerabilidades que afetam suas dependências e a respectiva gravidade.
-
Avaliação de risco
O ideal é que, após as avaliações de risco, não sejam encontradas vulnerabilidades. Porém, a possibilidade de encontrar brechas de segurança que possam afetar as aplicações é grande. Nesse caso, devem ser tomadas algumas decisões, baseadas em aspectos como a gravidade da vulnerabilidade, se existe correção disponível, quais os esforços necessários para a correção e se a vulnerabilidade é relevante para o aplicativo.
Na prática, é preciso equilibrar o esforço de atualização e mudanças e os benefícios que isso traz. Por exemplo, talvez você possa encontrar vulnerabilidades que realmente não afetam o aplicativo, então pode adiar a atualização da dependência para um momento posterior. Em outras palavras, em algumas circunstâncias, a empresa pode decidir aceitar o risco representado pelo problema de segurança que se descobriu em uma dependência.
Portanto, esta etapa do processo de mitigação é basicamente um raciocínio cuidadoso sobre os riscos e vantagens de tomar uma ação a respeito das vulnerabilidades.
-
Mitigação de risco
Depois que a empresa tem uma imagem clara da situação, como citamos, é possível ter vulnerabilidades que podem ser temporariamente ignoradas, mas outras que precisam ser corrigidas. Se houver uma correção para uma delas e a atualização for direta para o aplicativo, deve ser aplicada.
Caso não haja correção para uma vulnerabilidade que afeta uma de suas dependências, há as opções de colaborar com o autor ou fornecedor da dependência para resolver o problema ou encontrar uma solução alternativa para evitar a exploração da vulnerabilidade, por exemplo, realizando a aplicação de virtual patch.
Ao final deste processo, é bem possível que a organização tenha analisado as vulnerabilidades mais perigosas que podem afetar seus aplicativos.
Como a Veracode pode ajudar
A Veracode, líder mundial no fornecimento de soluções de validação de segurança e qualidade de software, ajuda as organizações a construírem um inventário dos componentes de open source e identificar vulnerabilidades.
O Veracode Application Security Platform analisa o código proprietário e o código-fonte aberto em uma única varredura, fornecendo visibilidade em todo o cenário do aplicativo. Além disso, quando novas ameaças surgem, a solução ajuda a identificar quais aplicativos de uma empresa são vulneráveis.
Utilizar soluções de terceiros é um ponto eficiente no desenvolvimento de aplicações, já que traz agilidade, recursos que podem contribuir com a operação e eficiência. Porém, como mostramos, a análise de segurança em bibliotecas de terceiros é tão importante quanto.
