Segundo este post do blog de segurança de Ruby on Rails, o plugin Restful_Authentication contém um falha de segurança quando se utiliza a funcionalidade de ativação de um cadastro.

De acordo com o post, o plugin aceita receber o parâmetro activation_code vazio assim:

http://localhost:3000/user/activate ou http://localhost:3000/activate/?activation_code=

dependendo das rotas criadas.

Isto geraria a seguinte consulta SQL:

SELECT * FROM users WHERE (users.activation_code IS NULL) LIMIT 1

A pessoa, então, poderia se logar sem senha com a primeira conta que tivesse o activation_code vazio, ou seja, com um dos usuários registrados.

Pelo post, o dono do plugin já foi notificado e o mesmo já providenciou a correção.

Se você usa, ou pensa em usar este plugin em algum de seus projetos, vale a pena pegar a última versão ou trocar a primeira linha do método de ativação para:

self.currentuser = params[:activationcode].blank? ? :false : User.findby_activationcode(params[:activation_code])

não esquecendo de acertar os nomes dos models caso tenha alterado.

SQL Injection é um problema comum de ocorrer se não tivermos cuidado com as informações vindas dos usuários, geralmente através de formulários. Um usuário malicioso poderia, por exemplo, tentar ter acesso a um cadastro manipulando o formulário de login de uma aplicação.

A seguir, criarei um cenário de login onde as informações vindas do formulário poderão ser manipuladas para ganhar acesso a aplicação, e depois, mostrarei como podemos evitar essa falha.

Este poderia ser um controller de autorização:

class User < ActiveRecord::Base
  def login
    @user = User.find(:first, 
                 :conditions => "login = '#{params[:name]}' 
                 AND password = '#{params[:password]}'")
  end
end

Isso é perigoso porque o símbolo # substitui a váriável diretamente pelo valor, sem nenhum tratamento. Então, se um usuário entrasse com o seguinte nome e senha:

params[:name] = ' OR '1'='1
params[:password] = ' OR '1'='1

geraria esta consulta no banco:

select * from users where login='' OR '1'='1' AND
                          password='' OR '1'='1' LIMIT 1

Com essa consulta, o usuário entraria no site com o login do primeiro usuário cadastrado no banco. Como a cláusula OR sempre será true, é como se fizéssemos o select sem cláusula where e isto retornaria a tabela inteira, mas com o LIMIT 1, apenas o primeiro usuário será retornado. Muitas vezes esse usuário pode ser até o administrador.

Para resolver essa falha, reescreveremos o método de login assim:

  def login
    @user = User.find(:first, 
            :conditions => ["login = ? AND password = ?"
            ,params[:name],params[:password]])
  end

Veja que agora passamos a condição via array sendo o primeiro índice a condição propriamente dita e, a partir do segundo índice, as variáveis, já tratadas pelo Rails, que serão substituídas pelo símbolo ? na mesma ordem que os símbolos aparecem.

Com isso, podemos entrar com aqueles valores anteriores que não haverá problemas, pois os caracteres especiais foram tratados.

Mass assignment é uma ferramenta muito poderosa que o ActiveRecord nos fornece. Com ela, podemos criar um objeto, passando todas as informações de um formulário, simplesmente com uma linha de código. Mas, sem tomar as devidas precauções, podemos nos encrencar feio criando falhas de segurança na aplicação.

Vejamos um exemplo simples de como isso pode acontecer. Suponha que tenhamos esse migration:

class CreateUsers < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.column :name, :string
      t.column :admin, :boolean
    end
  end

  def self.down
    drop_table :users
  end
end

esse controller:

class UserController < ApplicationController
  def create
    @user = User.create(params[:user])
  end
end

e esse view:

<form method="post" action="/user/create">
  <input type="text" name="user[name]" />
</form>

Tudo pronto e funcionando. Até que de repente, alguém resolver brincar um pouco com os dados do formulário e submete um form com os seguintes dados:

<form method="post" action="/user/create">
  <input type="text" name="user[name]" />
  <input type="hidden" name="user[admin]" value="1" />
</form>

Pronto. O usuário agora também é um administrador e pode fazer coisas desastrosas.

Podemos resolver isso dizendo para o model quais são os campos protegidos e que serão ignorados pelo mass assignment.

class User < ActiveRecord::Base
  attr_protected :admin
end

Outra forma de resolver o problema, é dizendo para o model quais são os campos permitidos para mass assignment.

class User < ActiveRecord::Base
  attr_accessible :name
end

A diferença entre as duas abordagens é, que na primeira, os campos são permitidos por default e somente os campos listados são protegidos, enquanto que na segunda acontece justamente o contrário.

Particularmente, acho a segunda abordagem mais segura, porque, se criarmos mais campos posteriormente, eles estarão protegidos por default.

A seguir, falarei de SQL Injection.

É verdade que utilizando todas as facilidades que o rails nos oferece, conseguimos criar aplicações de forma muito rápida. Isso é ótimo, mas às vezes, criamos uma aplicação tão rapidamente, que ou esquecemos de olhar alguns aspectos de segurança ou não sabemos o que acontece por debaixo dos panos e aí deixamos a aplicação exposta achando que tudo está funcionando redondo.

Vou escrever uma série de artigos mostrando alguns pontos que merecem uma certa atenção quando desenvolvemos nossas aplicações em ruby on rails.

Queries restritas ou scoped queries

Aplicações rails costumam usar IDs de registros nas urls, como por exemplo /contacts/show/28 ou para ser RESTful /contacts/28. Se tivéssemos construído nossa aplicação assim:

class User < ActiveRecord::Base
  has_many :contacts
end

class Contact < ActiveRecord::Base
  belongs_to :user
end

Os models são bem simples. Agora o controller:

class ContactsController < ApplicationController

  before_filter :require_signin

  def new
    @contact = Contact.new
  end

  def create
    contact = Contact.new params[:contact]
    contact.user_id = session[:user_id]
    contact.save
    redirect_to contact_url(contact)
  end

  def show
    @contact = Contact.find params[:id]
  end

  private

    def require_signin
      return false unless session[:user_id]
    end

end

Consegue ver o problema? Ele está no action show. Ainda não viu? Repare que, qualquer pessoa, estando logada no sistema, pode ver qualquer contato. Mesmo que o contato não pertença a ela. Simplesmente acessando uma url /contacts/show/id, passando o id que eu quiser, verei o contato em questão.

Para resolver isso, podemos fazer uma query com escopo definido. Como fazemos isso? Veja abaixo as modificações:

class ContactsController < ApplicationController

  # criamos o objeto @current_user
  before_filter :require_signin

  # safely looks up the contact
  before_filter :find_contact, 
          :except => [ :index, :new, :create ]

  def index
    @contacts = @current_user.contacts.find :all
  end

  def new
    @contact = @current_user.contacts.new
  end

  def create
    @current_user.contacts.create params[:contact]
    redirect_to contacts_url
  end

  def show
  end

  def edit
  end

  def update
    @contact.update_attributes params[:contact]
    redirect_to contact_url
  end

  def destroy
    @contact.destroy
    redirect_to contacts_url
  end

  private

    def require_signin
      @current_user = User.find session[:user_id]
      redirect_to(home_url) and return false 
               unless @current_user
    end

    def find_contact
      @contact = @current_user.contacts.find params[:id]
    end

end

Veja que agora, não acessamos mais o model Contact diretamente. Todas as consultas ficam restritas ao usuário logado no sistema e assim, apenas os contatos dele estarão visíveis.

O próximo artigo falará de mass assignment. Fiquem ligados.