Mantenha suas credenciais de código aberto protegidas

No início deste mês, um pesquisador chamado ChALkeR compartilhou sua pesquisa sobre credenciais vazadas em pacotes npm. Os resultados mostraram que credenciais, como tokens e senhas do npm e do GitHub, são frequentemente incluídas em pacotes npm publicados ou repositórios do GitHub. Na verdade, 13 dos 15 principais pacotes npm dependem de pacotes que vazaram credenciais, expondo assim seus usuários.

O post de ChALKeR é uma ótima leitura e a primeira análise de credenciais vazadas específica do npm que conheço, mas o problema não é novo. Há quase três anos, a busca do GitHub já facilitava encontrar chaves privadas (segundo relatos, expondo chaves da equipe do Chrome), e o Google pode revelar todo tipo de informação privada. À medida que o código fica mais fácil de encontrar, erros como esse também ficam mais fáceis de descobrir — mais um motivo para você tomar providências.

Para garantir que você está seguindo as diretrizes de segurança adequadas, baixe o guia da Snyk com 10 boas práticas de segurança para npm. Você vai aprender a adotar práticas seguras no uso do npm, úteis para desenvolvedores de Node.js e JavaScript.

Por que você deve se preocupar com credenciais vazadas

Vazar credenciais significa expor segredos que dão acesso a diferentes contas.

Os tipos mais comuns de credenciais vazadas são senhas, chaves de API e chaves privadas SSH. Essas chaves podem ser suficientes para que uma ferramenta automatizada — sua ou de um invasor — execute uma ação, como publicar uma nova versão de um pacote ou excluir código. O conjunto de ações que cada chave pode executar varia conforme a chave e o sistema.

Se você usa pacotes de código aberto, as credenciais que mais devem preocupar você são aquelas que permitem publicar código novo, como um token do npm ou uma chave de implantação do GitHub. Um invasor com acesso a essas credenciais pode facilmente publicar uma nova versão de “correção” com código malicioso, que muitas vezes você instalará sem perceber.

Se você hospeda seu projeto de código aberto em algum lugar, também deve tomar cuidado para não vazar informações sobre seus sistemas de execução. Isso vai além do npm: você pode expor suas chaves da AWS, chaves privadas SSH ou senhas de diferentes sistemas. Qualquer uma dessas chaves pode dar aos invasores acesso ao seu sistema, que pode ser usado para tudo, desde roubar sua propriedade intelectual e dados de usuários até simplesmente obter recursos de computação gratuitos (deixando a conta para você).

Sou desenvolvedor de código aberto. O que devo fazer?

Além de estar ciente dos riscos, você deve incorporar algumas boas práticas ao seu fluxo de trabalho e criar várias camadas de defesa para evitar erros. Confira algumas sugestões:

Evite comandos genéricos como git add *

O uso de curingas pode incluir facilmente arquivos locais que não deveriam ser compartilhados. Isso é especialmente importante ao adicionar pastas inteiras (por exemplo, git add dirname), pois isso também inclui arquivos ocultos (dot).

Em vez de usar curingas, especifique cada arquivo que você vai enviar ou use git add -p para revisar cada alteração adicionada.

Inclua arquivos confidenciais no .gitignore e no .npmignore

Tanto o git quanto o npm permitem manter uma lista local de arquivos excluídos de pacotes e commits. Você pode usar essa lista como medida de segurança para evitar a inclusão acidental de arquivos confidenciais. Se você não configurar exclusões, o npm ainda vai ignorar alguns arquivos, mas o git incluirá todos. Independentemente das configurações padrão, nenhuma das ferramentas conhece sua aplicação tão bem quanto você. Por isso, é melhor editar esses arquivos por conta própria.

Alguns arquivos que exigem atenção:

• Arquivos de configuração de CI (por exemplo, .travis.yml, circle.yml)

• Dockerfile e docker-compose.yml

• Arquivos de saída do processo de build (por exemplo, gypi)

• Scripts de implantação personalizados (por exemplo, qualquer arquivo em /deploy/ ou /scripts/).

ChALKeR lista alguns outros exemplos no post, e você pode consultar os arquivos de exemplo .gitignore do GitHub para se inspirar.

Vale lembrar que as regras de exclusão padrão mais abrangentes do npm só foram introduzidas no npm@2.14.1. Portanto, atualize para essa versão ou uma mais recente.

Use criptografia ou variáveis de ambiente ao publicar por meio de CI

Se você publica no npm por meio da CI, ela precisa ter acesso ao seu token do npm. É fácil incluir esse token por engano nos arquivos de configuração da CI e acabar expondo-o.

Sempre que possível, use uma variável de ambiente para armazenar o token. Assim, ele fica fora do controle de versão e é ocultado na saída (pelo menos no Travis e no Circle). Se, por algum motivo, você precisar incluir uma chave no controle de versão (por exemplo, se quiser enviar conteúdo de volta ao GitHub), lembre-se de criptografá-la adequadamente.

git-secrets: hook do git que impede commits com credenciais

Michael Dowling, da AWS Labs, lançou recentemente uma ferramenta útil chamada git-secrets. Ela se conecta ao git commit e interrompe o commit se ele incluir padrões que pareçam credenciais. É uma boa camada de segurança focada no conteúdo, que complementa a proteção baseada em nomes de arquivo sugerida anteriormente.

É importante notar que você precisa detectar essas credenciais antes de fazer o commit (ou, mais precisamente, antes de enviar as alterações), como essa ferramenta faz. Em projetos de código aberto, testar como parte da CI ou do processo de pull request é tarde demais: as credenciais já vazaram.

Invalide as credenciais vazadas

Por fim, se você descobrir que já vazou alguma chave ou senha, invalide esses tokens rapidamente.

Remover o token da versão ou do branch mais recente não será suficiente. Mesmo que você apague as referências do histórico, cópias da chave continuarão por aí — mesmo que você já as tenha removido do GitHub e do npm. A internet não esquece. Também é uma boa ideia verificar se alguém usou a chave nesse meio-tempo para publicar código malicioso ou acessar seus sistemas.

Uso pacotes de código aberto. O que devo fazer?

Como usuário de pacotes de código aberto, há pouco que você possa fazer. Ao usar um pacote, você confia nele explicitamente e, implicitamente, nas dependências que ele traz. Falhas de segurança nessas dependências podem comprometer seus próprios sistemas, seja por credenciais vazadas ou vulnerabilidades (você pode usar a Snyk para lidar com estas últimas). Segundo ChALKeR, as credenciais que ele descobriu já foram invalidadas pelo GitHub e pelo npm, respectivamente. Credenciais invalidadas não representam mais um risco à segurança (desde que não tenham sido exploradas nesse meio-tempo).

Ainda assim, se quiser agir de forma preventiva, você pode auditar suas dependências e verificar se elas compartilham informações que, na sua opinião, deveriam ser mantidas em sigilo. Alguns comandos bash podem ajudar você a encontrar os arquivos ocultos relevantes nas dependências. Depois, cabe a você decidir se eles contêm informações privadas.

Veja um comando bash para Mac/Linux que pode ajudar você a começar. Ele encontra alguns desses arquivos, remove duplicatas e os exibe junto com o nome do arquivo:

find . \( -name '*.gypi' -o -name '.npmrc' -o -name '.travis.yml' \) | xargs md5 -r | sort | awk '{print $2" "$1}' | uniq -f1 | sort | awk '{print "echo "$1";cat "$1}'

Resumo

Desenvolver de forma aberta é ótimo, mas nem tudo deve ser compartilhado. O vazamento de credenciais coloca seus consumidores em risco e, consequentemente, os usuários deles também.

Mantenha suas credenciais separadas do código e deixe todos cientes e atentos a esse risco. Procure vazamentos durante as revisões de código e inclua essa verificação nas práticas padrão. Além de processos, implemente as camadas de segurança descritas acima para detectar erros humanos. Por fim, se descobrir que houve um vazamento, aja com rapidez: invalide os tokens, avise seus usuários e verifique se há vestígios de código malicioso.