Mais segurança para Gemfiles do Ruby: guia passo a passo com o Snyk

Ruby é uma linguagem bem definida e cuidadosamente projetada, que existe desde meados da década de 1990. Em 2004, Ruby incorporou o RubyGems como gerenciador de pacotes. RubyGems é usado para gerenciar bibliotecas e dependências em um formato independente conhecido como gem. A interface do RubyGems é uma ferramenta de linha de comando que se integra ao runtime do Ruby e permite adicionar ou atualizar Gemfiles em um projeto.

Analisei três plataformas Ruby e encontrei vulnerabilidades que me surpreenderam. Veja o que observar para aumentar a segurança do seu Gemfile do Ruby e o que fazer caso encontre vulnerabilidades.

O papel do gerenciamento de pacotes

Assim como outras linguagens, Ruby oferece algumas opções de gerenciamento de pacotes. Uma das mais usadas para gerenciar aplicações é o Bundler, que, na verdade, é instalado inicialmente como uma gem do Ruby.

Um gerenciador de pacotes como o Bundler pode instalar muitas gems listadas em um Gemfile, enquanto o RubyGems exige a instalação de cada uma separadamente com gem install. Isso simplifica o gerenciamento de pacotes Ruby quando você precisa manter ou instalar um grande conjunto de gems em uma aplicação.

Os gerenciadores de pacotes certamente facilitam a manutenção de bibliotecas e dependências em uma aplicação. No entanto, é importante saber o que você está usando e quais riscos podem surgir na sua stack. Uma simples análise de segurança pode ser feita rapidamente para identificar possíveis problemas, economizando tempo e dinheiro e preservando a confiança dos usuários finais no futuro.

Um olhar sobre as vulnerabilidades

Antes de falar sobre o que encontrei ao analisar plataformas que já usei, quero destacar alguns pontos:

• Como usuário e desenvolvedor dessas plataformas, fiquei surpreso com o que encontrei. Isso reforça que desenvolver com segurança exige conscientização e aprendizado contínuos.

• Em todos os casos abaixo, entrei em contato com cada comunidade para conversar sobre as vulnerabilidades e garantir que soubessem dos problemas, embora muitas já tivessem correções.

Spree Commerce

O Spree é uma das plataformas de comércio eletrônico mais usadas no ecossistema Ruby. Sempre foi uma das minhas opções favoritas de código aberto para e-commerce. O Spree existe desde 2007 e conta com uma grande comunidade de desenvolvedores e empresas que ajudam a mantê-lo.

O primeiro passo da análise é criar um manifesto Gemfile.lock, que pode ser analisado com a ferramenta Snyk CLI. Depois de clonar o repositório do Spree e executar o Bundle install, o arquivo de lock é criado com as bibliotecas e dependências necessárias do Gemfile, a partir do manifesto Gemfile do projeto.

Uma dica para quem usa OSX e brew com MariaDB instalado: a instalação da gem MySQL2 pode gerar um erro durante o processo do Bundler. Primeiro, precisei executar brew install openssl e definir o caminho usando export LIBRARY_PATH=$LIBRARY_PATH:/usr/local/opt/openssl/lib/

Depois de criar o arquivo de lock, execute [snyk test](https://snyk.io/blog/snyk-cli-cheat-sheet/). A análise encontrou as seguintes vulnerabilidades de gravidade média:

1Tested 142 dependencies for known issues, found 2 issues, 84 vulnerable paths.
2
3Issues with no direct upgrade or patch:
4  ✗ Information Exposure [Medium Severity][https://snyk.io/vuln/SNYK-RUBY-ACTIONCABLE-20338] in actioncable@6.1.4
5    introduced by spree@4.3.0.alpha > spree_core@4.3.0.alpha > active_storage_validations@0.9.5 > rails@6.1.4 > actioncable@6.1.4 and 1 other path(s)
6  No upgrade or patch available
7  ✗ Web Cache Poisoning [Medium Severity][https://snyk.io/vuln/SNYK-RUBY-RACK-1061917] in rack@2.2.3
8    introduced by actionpack@6.1.4 > rack@2.2.3 and 81 other path(s)
9  No upgrade or patch available

A análise acima identificou dois problemas de gravidade média.

Exposição de informações é introduzida por uma dependência indireta, por meio de uma gem chamada alpha com spree_core. Como o nome sugere, isso pode permitir que dados sejam obtidos remotamente da plataforma principal.

A outra vulnerabilidade identificada é envenenamento de cache da Web, introduzida por uma dependência indireta com uma gem chamada actionpack. Na prática, isso permite que um invasor engane o cache do servidor para gerar respostas maliciosas a solicitações válidas. Confira esta publicação sobre envenenamento de cache para saber mais.

Sinatra

Sinatra é um servidor Web leve e portátil. Além de ser um dos meus favoritos para demonstrações e aplicações pequenas, ele permite colocar aplicações no ar com muita rapidez e facilidade. Com mais de 160 milhões de downloads até hoje, é usado em projetos dos mais variados tipos.

Desta vez, usei o Bundler para executar bundle init em um novo diretório e criar um Gemfile vazio. Depois, editei o arquivo Gemfile e adicionei gem 'sinatra' ao final. Também adicionei a gem erubis, bastante usada para criar templates HTML e agilizar o desenvolvimento frontend — além de combinar muito bem com Sinatra.

1# frozen_string_literal: true
2
3source "https://rubygems.org"
4
5gem 'sinatra'
6gem 'erubis'

Depois de salvar o Gemfile, instale todas as dependências necessárias executando bundler install. Após alguns segundos, o gerenciador de pacotes cria um manifesto Gemfile.lock, pronto para a análise de segurança. Minha análise mostrou o seguinte:

1Tested 7 dependencies for known issues, found 2 issues, 3 vulnerable paths.
2
3Issues with no direct upgrade or patch:
4  ✗ Cross-site Scripting (XSS) [Medium Severity][https://snyk.io/vuln/SNYK-RUBY-ERUBIS-20482] in erubis@2.7.0
5    introduced by erubis@2.7.0
6  No upgrade or patch available
7  ✗ Web Cache Poisoning [Medium Severity][https://snyk.io/vuln/SNYK-RUBY-RACK-1061917] in rack@2.2.3
8    introduced by sinatra@2.1.0 > rack@2.2.3 and 1 other path(s)
9  No upgrade or patch available

Investiguei a vulnerabilidade da gem erubis (CWE-79). A documentação contém um método de escape incorreto que pode deixar a aplicação vulnerável a um ataque XSS. Na documentação do erubis, muitos exemplos usam <%= expr %>, que não escapa as variáveis armazenadas no template. Para fazer o escape corretamente e impedir que elementos HTML armazenados sejam exibidos nos templates, é preciso usar <%== expr %>.

Como desenvolvedor, é importante não apenas analisar o código em busca de vulnerabilidades, mas também entender as ameaças como parte da diligência necessária para desenvolver com segurança.

Ruby on Rails

Rails é uma das gems mais usadas em todo o ecossistema Ruby. Com mais de 293 milhões de downloads no total pelo RubyGems, é uma escolha óbvia e popular para o desenvolvimento de aplicações Web.

Ao fazer uma análise de segurança usando o Snyk Vulnerability Database, encontrei várias versões que exigem atenção. No entanto, a versão atual (6.1.4 na época da publicação) não tem vulnerabilidades conhecidas.

Execute gem install rails_,_e crie um projeto Rails vazio executando rails new myapp. Isso cria um novo template Rails vazio para servir de base para a aplicação. Depois de configurar as bibliotecas e dependências, fiz uma análise de segurança com [snyk test](https://snyk.io/blog/snyk-cli-cheat-sheet/). Ela identificou as seguintes vulnerabilidades no manifesto de pacotes.

1Tested 72 dependencies for known issues, found 2 issues, 36 vulnerable paths.
2
3Issues with no direct upgrade or patch:
4  ✗ Information Exposure [Medium Severity][https://snyk.io/vuln/SNYK-RUBY-ACTIONCABLE-20338] in actioncable@6.1.4
5    introduced by rails@6.1.4 > actioncable@6.1.4
6  No upgrade or patch available
7  ✗ Web Cache Poisoning [Medium Severity][https://snyk.io/vuln/SNYK-RUBY-RACK-1061917] in rack@2.2.3
8    introduced by capybara@3.35.3 > rack@2.2.3 and 34 other path(s)
9  No upgrade or patch available

Ao investigar melhor, vi que a gem Action Cable, uma dependência do Rails, apresenta um alerta de possível exposição de informações. O problema parece ter sido identificado em 2016, mas não há uma correção na biblioteca principal do framework. Depois de analisar com mais atenção o PR listado no Snyk Vulnerability Database, encontrei uma solução alternativa no código que mitiga o problema. Ela foi sugerida em 2019.

O outro problema é introduzido pela gem Rack e também está relacionado ao envenenamento de cache da Web, assim como o problema do Spree Commerce mencionado acima.

Fortaleça as comunidades contribuindo

Adoro trabalhar diretamente com código, especialmente investigar vulnerabilidades identificadas e entendê-las no nível do código depois de pesquisar sobre o assunto.

Leva apenas alguns instantes para fazer uma análise e verificar se há vulnerabilidades conhecidas nas bibliotecas, no código ou nas plataformas que você usa. Isso pode economizar tempo e proteger os usuários finais. Desenvolvedores, equipes ou empresas que usam essas plataformas em produção podem não saber exatamente o que estão incorporando. Espero que esta publicação ajude algumas equipes a se manterem seguras.

Lembre-se também de que essas comunidades fazem um trabalho incrível criando bibliotecas para todos usarmos. Por isso, é importante contribuir sempre que possível. Até mesmo ajudar com a documentação ou testar uma versão candidata já faz diferença. Sou apenas um desenvolvedor, e esta é apenas uma publicação. Para realmente causar um grande impacto na segurança, incentivo todos vocês a testar os projetos e contribuir com as correções.