/ Git

Putz, comitei meu .env! E agora?

Em primeiro lugar, gostaria de dizer que: amigo ou amiga, você não está só! Neste post, vamos analisar o que realmente ocorreu e entender como lidar com isto.

O que foi comprometido, de fato?

Num primeiro momento, vamos chorar e passar nervoso analisar o que foi comprometido e por quanto tempo. Se seu repositório era privado, onde poucas pessoas possuem acesso, ou o arquivo .env só continha informações inofensivas como o nome do app ou uma URL pública indicando a URL base da aplicação (ou qualquer coisa que o usuário já poderia deduzir ou acessar), então já podemos manter a calma.

Agora, num caso um pouco pior (e mais próximo da realidade), seu repositório é público e o arquivo .env poderia conter informações sobre banco de dados, chaves de API ou configurações gerais da aplicação, que poderiam ser usadas para um ataque. Isto vale para informações do ambiente loacal/development TAMBÉM!

Neste caso, a PRIORIDADE seria trocar cada acesso, senha, token e chave de API que vazou e poderia ser usado. Quanto antes isto for feito, menores as chances de que um ataque seja realizado com sucesso. Cada segundo com a informação válida no ar é um segundo com a porta aberta a qualquer ataque.


Foto por Verne Ho / Unsplash

Limpando a bagunça

Ok, já trocamos nossas senhas de password para 123456, regeneramos todos tokens, chaves de API/SSH e estamos nos sentindo SUPER seguros (só que não), agora podemos começar a limpar a bagunça que fizemos em nosso repositório.

A primeira etapa é não comitar novamente estas informações. Para isto vamos inserir nosso .env no .gitignore.
Comitamos e executamos um git push para sincronizar o .gitignore com o repositório remoto.

A segunda etapa é remover os arquivos do histórico. No caso do Git, temos o comando nativo git filter-branch e também temos o BFG Repo-Cleaner.

BFG Repo-Cleaner

Explicarei pela opção mais rápida que é o BFG. Basicamente o BFG é um software open-source escrito em Scala que permite realizar ações em massa em um repositório Git, ao estilo do filter-branch, porém de uma forma mais rápida e simplificada.

Começaremos clonando nosso repositório em outro lugar, com a opção --mirror, que retornará o repositório em formato .git, sem os arquivos. É interessante fazer um backup deste repositório, pois ele contém uma cópia bruta de todos seus commits.

Em seguida, rodamos o BFG através do comando bfg --no-blob-protection --delete-files .env meu-novo-repositorio.git
O arquivo será removido de todo o histórico de versionamento do Git, incluindo seu commit mais recente.

Este procedimento também vale para outros arquivos, como o wp-config.php, por exemplo: bfg --no-blob-protection --delete-files wp-config.php meu-novo-repositorio.git

Com o repositório limpo, entraremos nele e gravaremos o novo histórico, com o comando que o próprio BFG nos sugere: git reflog expire --expire=now --all && git gc --prune=now --aggressive
Por fim, rodamos um git push para sincronizar com o repositório remoto.

Restaurando o backup

Caso seja necessário usar o backup, basta entrar na pasta do repositório backup e rodar um git push, ele irá substituir todas as mudanças que foram feitas com o estado do repositório no momento em que ele foi baixado.

Fontes e Recursos

BFG Repo-Cleaner
Removing sensitive data from a repository - GitHub

Foto de capa por Nik Shuliahin / Unsplash

Matheus Pratta

Matheus Pratta

Desenvolvedor web que ama design, fotografia e cinema. Atualmente morando em algum lugar entre São Paulo e Minas Gerais. 🍃🌄

Ler Mais