Boas práticas que podem evitar a exposição de tokens de desenvolvimento

Boas práticas que podem evitar a exposição de tokens de desenvolvimento

A segurança da informação não é somente tecnologia e ferramentas. É uma mentalidade, um caminho pelo qual uma empresa escolhe andar sempre que precisa organizar e manter ambientes de infraestrutura, redes de computadores, políticas internas, gestão de acessos a colaboradores e outros. Porém, o avanço encontra barreiras se os produtos que precisam ser protegidos ou que ajudam a proteger não tiverem segurança no seu DNA.

Camadas de segurança ativas em uma empresa perdem força quando há produtos que foram mal desenvolvidos do ponto de vista da proteção cibernética. Por isso, listamos algumas práticas fundamentais para que um produto tenha segurança desde a origem.

Segurança de aplicações

Os ataques cibernéticos encontram inúmeras portas de entrada em um ambiente. Portas como a das configurações malfeitas em um servidor, ou a da engenharia social, como quando um colaborador acessa um arquivo malicioso e infecta toda a rede com um malware. No entanto, ainda que fragilidades estejam mapeadas e solucionadas, ainda que a arquitetura de proteção esteja bem desenhada, se o ambiente de uma empresa possuir aplicativos e sistemas web mal desenvolvidos, essas camadas de seguranças ativas perdem força.

Porque as informações já foram expostas por meio do descuido no desenvolvimento.

A entrega ágil de um sistema é o que todas as empresas esperam, porém, a velocidade não pode comprometer fatores de segurança. Esse entendimento deu origem ao conceito de desenvolvimento seguro, que consiste em um conjunto de práticas e ferramentas que auxiliam na criação de produtos que sejam seguros desde o seu nascimento, levando em consideração pontos importantes em torno dos riscos cibernéticos.

O desenvolvimento com qualidade, obedecendo ao prazo, e com a segurança adequada é a definição de uma entrega bem-sucedida. Além da entrega, também há a manutenção da segurança do software em seu ciclo de vida e da infraestrutura subjacente. As estratégias de desenvolvimento seguro devem abordar alguns pontos, como:

  • Políticas no armazenamento de informações e código-fonte;
  • Recursos humanos e gerenciamento de fornecedores;
  • Ativos utilizados;
  • Canais de comunicação.

OWASP

Quando falamos em desenvolvimento seguro, além das estratégias mencionadas, é importante ressaltar a referência global neste assunto que é a OWASP – Open Web Application Security Project. O OWASP traz em sua sigla, o significado de Projeto Aberto de Segurança em Aplicações Web, que constitui uma comunidade global de desenvolvedores, pesquisadores e especialistas em segurança da informação, que possuem o objetivo de encontrar e mitigar vulnerabilidades em aplicações web. Eles trocam conhecimentos de forma aberta e disponibilizam gratuitamente conteúdo para auxiliar os profissionais da área.

A principal contribuição dessa comunidade, é o ranking anual OWASP Top 10. Trata-se de um relatório atualizado frequentemente, com foco nos dez riscos mais críticos e relaciona as brechas mais críticas, comuns e perigosas quando o assunto é desenvolvimento de projetos web. A última listagem é do ano de 2021 e são eles:

  • A01:2021 – Broken Access Control: As falhas no controle de acesso levam à exposição de informações, modificação ou exclusão de dados por usuários não autorizados;
  • A02: 2021 – Cryptographic Failures: Se mostram como um alto fator de exposição de dados confidenciais;
  • A03: 2021 – Injection: As injectionsmais comuns afetam o SQL e NoSQL, comandos do sistema operacional e o LDAP;
  • A04: 2021 – Insecure Design: É uma área que inclui a falta de proteção para dados armazenados, problemas de programação lógica e exibição de conteúdos que revelam informações confidenciais;
  • A05:2021 – Security Misconfiguration: O crescimento da categoria foi alertado pela organização devido às contínuas mudanças em software altamente configurável;
  • A06: 2021 – Vulnerable and Outdated Components: Essa categoria possui uma relação direta com o grande aumento da utilização de componentes e bibliotecas de terceiros sem a correta validação de segurança, o que pode gerar grandes volumes de vulnerabilidades em aplicações;
  • A07: 2021 – Identification and Authentication Failures;
  • A08: 2021 – Software and Data Integrity Failures;
  • A09: 2021 – Security Logging and Monitoring: É uma categoria que visa os problemas que podem dificultar a análise de uma violação de dados ou outra forma de ataque;
  • A10: 2021 – Server-Side Request Forgery: A adoção de serviços em nuvem e arquiteturas cada vez mais complexas aumentaram a gravidade dos ataques SSRF.

Com o estudo de caso abordado neste informativo, salientamos a vulnerabilidade A04: 2021 – Insecure Design da OWASP como ponto de atenção para esse caso, pois trata-se de um contexto de exposição de conteúdo com informações confidenciais.

Em alguns ataques cibernéticos recentes, pudemos identificar algumas falhas críticas nesses quesitos e exemplificaremos adiante.

Existem inúmeras ferramentas que auxiliam os desenvolvedores na manutenção, colaboração e revisão de código, como GitHub e Postman, porém por uma falta de cuidado acabam expondo informações importantes e valiosas. Traremos um dos casos identificados,  com a finalidade de informar sobre o acontecido e trazer a conscientização para o armazenamento de código, também preservaremos os dados sensíveis para não expor ainda mais a empresa.

O uso da plataforma Postman para armazenamento de chaves API

O Postman é uma plataforma utilizada para construção e uso de APIs (Application Programming Interface). Ele simplifica cada etapa do ciclo de vida e agiliza a colaboração, porém é uma plataforma aberta e que todos podem ter acesso se o conteúdo estiver como público.

Nesse caso específico, identificamos um repositório completo com informações críticas, toda a estrutura do código-fonte e possíveis ligações com outros fornecedores, implicando também na exposição de outras empresas. Nas imagens abaixo, podemos identificar chaves de API, informações sensíveis de fornecedores e credenciais expostas, sendo um ponto muito fácil de exploração e ataque.

As consequências da exposição da chave API

Uma chave de API (ou token) somente deve ser inserida em um banco de dados privado e com restrições. Não deve estar exposta publicamente. A divulgação desse dado pode trazer sérias consequências ao ambiente.

Figura 1 – Identificado repositório com chaves de API expostas

 

Informações sensíveis de fornecedor

Aqui, encontramos dados sensíveis como nome, número do documento, endereço, meio de pagamento, descrição, todos com o nome exposto e texto claro. Com isso, é possível identificar os atores envolvidos facilmente e podendo utilizar esses dados para alguma fraude.

Figura 2 – Identificado repositório com dados sigilosos de fornecedores e notas fiscais

Credenciais expostas

Esse é o dado mais crítico encontrado, pois facilmente podemos identificar o nome do funcionário, e-mail e a senha de acesso. O que traz diversas consequências se utilizado por agentes mal-intencionados.

Figura 3 – Repositório contendo endereço de e-mail e senha em texto claro

 

Figura 4 – Repositório contendo endereço de e-mail e senha em texto claro

Assim, vemos que alguns repositórios são apenas de teste ou homologação, porém as informações ali contidas são críticas e que podem direcionar o acesso a outros sistemas e infraestruturas.

Então, deixamos o alerta para a conscientização no uso desses tipos de ferramentas,  sempre as utilizando de forma privada e também com cautela no tipo de informação adicionada, pois nenhuma plataforma é totalmente segura.

Desenvolvedores precisam estar conscientes a respeito das práticas de segurança e o envolvimento de uma equipe especializada nesse assunto durante todo o ciclo de vida do desenvolvimento. Para que a entrega do produto seja bem-sucedida e a segurança esteja presente, o que agrega valor ao produto final.

Related Posts