Segurança em Rails

2014 May 22, 11:39 h

O assunto segurança é bem complicado, este post não tem a intenção de ser a fonte completa de tudo relacionado a segurança no mundo Ruby on Rails mas apenas listar algumas informações e ferramentas úteis. Antes de começar alguns links importantes que, se você ainda não conhecia, precisa ter nos seus favoritos:

Aliás, um comentário sobre o termo. Nunca se pode dizer "minha aplicação está segura", o máximo que podemos dizer é "minha aplicação parece não ter nenhuma vulnerabilidade conhecida." Só porque você não conhece, não significa que as vulnerabilidades não existam, e as chances são que existam e você simplesmente a ignora. O único tipo de aplicação "segura" é aquela que está completamente off-line numa localização geográfica desconhecida em um bunker anti-nuclear. Tirando isso, qualquer outra coisa é "quebrável".

Bundler Audit

Como disse antes, não é fácil manter um projeto. Depois de algum tempo as gems são atualizadas e você não fica sabendo disso. Quando são apenas adições de algumas novas funcionalidades, não há com o que se preocupar, mas como você fica sabendo se uma das dezenas de gems que sua aplicação utiliza recebeu atualizações de segurança.

Para isso o pessoal do RubySec mantém um banco de dados, o Ruby Advisory DB que concentra e organiza os diversos security advisories. Você pode contribuir se tiver gems de código aberto que receberam contribuições para fechar vulnerabilidades.

E para quem quer automatizar o processo de encontrar esses advisories, o RubySec também tem o Bundler Audit. Ele funciona usando o Advisory DB e cruzando com as versões específicas de gems que estão listadas no Gemfile.lock do seu projeto.

Apenas instale a gem com

1
gem install bundler-install

E execute a partir da raíz do seu projeto:

1
bundle-audit

Ele vai lhe dar uma saída parecida com esta:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Insecure Source URI found: git://github.com/Codeminer42/axlsx.git
Name: actionpack
Version: 3.2.16
Advisory: OSVDB-103440
Criticality: Unknown
URL: https://osvdb.org/show/osvdb/103440
Title: Denial of Service Vulnerability in Action View when using render :text
Solution: upgrade to >= 3.2.17

Name: actionpack
Version: 3.2.16
Advisory: OSVDB-103439
Criticality: Unknown
URL: https://osvdb.org/show/osvdb/103439
Title: XSS Vulnerability in number_to_currency, number_to_percentage and number_to_human
Solution: upgrade to ~> 3.2.17, ~> 4.0.3, >= 4.1.0.beta2

Name: mini_magick
Version: 3.5.0
Advisory: OSVDB-91231
Criticality: High
URL: https://osvdb.org/show/osvdb/91231
Title: MiniMagick Gem for Ruby URI Handling Arbitrary Command Injection
Solution: upgrade to >= 3.6.0

Name: nokogiri
Version: 1.5.10
Advisory: OSVDB-101458
Criticality: Unknown
URL: https://www.osvdb.org/show/osvdb/101458
Title: Nokogiri Gem for Ruby External Entity (XXE) Expansion Remote DoS
Solution: upgrade to ~> 1.5.11, >= 1.6.1

Name: nokogiri
Version: 1.5.10
Advisory: OSVDB-101179
Criticality: Unknown
URL: https://www.osvdb.org/show/osvdb/101179
Title: Nokogiri Gem for JRuby Crafted XML Document Handling Infinite Loop Remote DoS
Solution: upgrade to ~> 1.5.11, >= 1.6.1

Unpatched versions found!

Seguindo o exemplo acima, precisaríamos fazer o seguinte:

1
bundle update nokogiri mini_magick rails

Você pode precisar alterar o arquivo Gemfile se a versão específica estiver declarada antes de realizar o update. E depois rode o bundle-audit novamente para ter certeza que está tudo bem. Apenas cuidado com os casos onde você aponta diretamente para um repositório do Github em vez do Rubygems.org, pois ele não tem como checar se o que você está puxando do Github tem vulnerabilidades conhecidas ou não.

Para atualizar seu bundler-audit antes de realizar um novo scan, faça:

1
bundle-audit update

Bônus: Rack-Attack

Além da análise estática de código para avaliar segurança, uma adição que pode ser interessante dependendo do tipo de site que você usa é o Rack-Attack.

Digamos que avaliando seus logs você perceba que seu site está sendo muito consumido por web scrappers, robôs do tipo que ficam capturando seu conteúdo. Se for robôs de motores de busca como Google, Bing, tudo bem, mas você vai encontrar mais do que isso.

Imagine que além de scrappers consumindo demais, você tenha tentativa de ataques de força-bruta, como scripts automatizados tentando diversas combinações de usuários e senhas até conseguir acertar um.

Ou imagine simplesmente que você quer ou criar uma lista de IPs que você quer permitir (se seu site estiver em beta fechado, por exemplo) ou uma lista negra que você já sabe que quer bloquear.

Tudo isso pode ser feito diretamente no web server ou balanceador de carga. Mas se você estiver fazendo deployment em ambientes fechados como Heroku, não vai ter acesso à essa configuração.

Para isso existe o Rack::Attack, que é um middleware Rack que você instala de modo simples diretamente na sua aplicação Rails e pode customizá-lo de diferentes formas. A instalação básica é simples. Apenas acrescente à sua Gemfile:

1
gem 'rack-attack'

E adicione ao arquivo config.ru, antes da linha do comando run:

1
use Rack::Attack

E se quiser customizar, comece adicionando o arquivo config/initializers/rack-attack.rb com o seguinte:

1
2
3
class Rack::Attack
  Rack::Attack.cache.store = ActiveSupport::Cache::MemoryStore.new # defaults to Rails.cache
end

A documentação no Github tem muito mais detalhes. Nos aspectos de detectar padrões de invasão por força bruta ele se inspira no famoso fail2ban (que você pode usar para proteger, por exemplo, o SSH de seu servidor).

Vale a pensa aprender mais sobre esse assunto.

tags: learning beginner rails security

Comments

comentários deste blog disponibilizados por Disqus