Segurança no Rails: 9 vulnerabilidades que você deve evitar
Nesta artigo rápido você vai conhecer alguns tipos de vulnerabilidades que podem trazer grandes riscos a sua aplicação Ruby on Rails e também vai aprender algumas caminhos para soluciona-las facilmente.
Entenda o problema
Segundo o Grupo Gartner, que é responsável por realizar pesquisas tecnológicas, é estimado que 75% dos ataques a websites são direcionados a camada de aplicação, e que dentre 300 sites auditados, 97% estavam vulneráveis a ataque.
O Ruby on Rails é um framework maduro e seguro, então, porque mesmo assim devemos nos preocupar com estes dados?
Como resposta, essas brechas de segurança geralmente são causadas pela falta do uso de boas práticas no processo de desenvolvimento.
Utilize esta leitura para conhecer estes riscos e ser capaz de evitá-los.
As 9 vulnerabilidades
A seguir, você verá uma lista de vulnerabilidades e dicas sobre como prevenir esses problemas de segurança.
1- Code Injection
Falha de segurança que permite a execução de comandos Ruby ou do Sistema Operacional.
Como isso ocorre?
No ruby existe um método muito poderoso chamado eval que executa códigos ruby que estão dentro de uma String.
Quando este método é utilizado de forma imprudente, acaba gerando uma brecha para ataques.
Veja a seguir um exemplo de MAL USO deste método:
|
1 2 3 |
params[:name] # "Kernel.exec('Qualquer comando do sistema operacional')" eval(params[:name]) |
Assim, através de um parâmetro, sua aplicação permite a execução de qualquer comando ruby ou do sistema operacional.
Prevenção:
O método eval é muito poderoso e deve ser utilizado com muita cautela. Você nunca deve utilizá-lo caso o argumento venha do usuário e não esteja devidamente validado e filtrado!
2- Sql Injection
Vulnerabilidade que permite a manipulação de uma query SQL, resultando no acesso a partes do banco de dados sem autorização.
Como isso ocorre?
A vulnerabilidade é produzida quando uma query utiliza uma declaração passada por um usuário sem fazer o saneamento deste dado.
A seguir, veja um exemplo de COMO NÃO CRIAR uma query:
|
1 2 3 |
params[:search] # "'); DROP TABLE users; SELECT * FROM products WHERE (name LIKE '%" User.where("first_name LIKE '%#{params[:search]}%'") |
Utilizando uma única string, você permite que params[:search] contenha comandos sql mal intencionados.
Prevenção:
Para obrigar que o dado seja sanitizado antes de ser utilizado em sua query, insira ele como um parâmetro
Veja como passar a declaração por meio de um parâmetro:
|
1 |
User.where("first_name LIKE ?", "%#{params[:search]}%") |
3- Privilege Escalation
Dependendo da forma que uma query de busca é implementada, o usuário pode ter acesso a dados mesmo sem autorização.
Como isso ocorre?
Imagine um sistema onde o usuário tem um projeto e qualquer outro usuário pode acessar este projeto.
Estaria correto realizar essa busca da seguinte forma.
|
1 |
@project = Project.find(params[:id]) |
Porém, se o projeto é acessível apenas pelo seu proprietário, está query deixa uma brecha para que outras pessoas consigam encontrá-lo (basta tentar passar ids aleatórios).
Prevenção:
Utilize associações para que o usuário encontre apenas projetos que pertencem a ele.
|
1 |
@project = @current_user.projects.find(params[:id]) |
4- Sensitive Files
A maior parte das aplicações Ruby on Rails são de código livre e estão hospedadas em repositórios públicos.
Nesse caso, alguns arquivos são sensíveis, ou seja, podem conter dados sigilosos, como por exemplo:
|
1 2 3 4 |
/config/database.yml - Pode conter credenciais de Produção. /config/initializers/secret_token.rb - Contem o segredo para criar um hash de um cookie de sessão. /db/seeds.rb - Dados iniciais do sistema, como um usuário admin por exemplo. /db/development.sqlite3 - Pode conter dados reais. |
Prevenção:
Tome cuidado com o conteúdo dos arquivos que você envia para o repositório do projeto. Utilize Encrypted Credentials para proteger suas credenciais e o gitignore para não enviar determinados arquivos.
Caso tenha necessidade, veja este guia sobre como usar o Encrypted Credentials.
5- Cross-Site Scripting (XSS)
Este é um tipo de ataque malicioso que injeta código executável no lado do cliente.
Como isso ocorre?
Quem realiza o ataque faz isso enviando um dado para ser salvo pela aplicação web. Este dado é um código executável, que é processado quando a aplicação tenta exibi-lo no lado do cliente.
Imagine um cenário onde você quer disponibilizar ao usuário a opção de adicionar tags html a descrição de um texto. Na hora de exibir esta informação, você utilizou o método html_safe para que as tags sejam aplicadas a sua página.
|
1 |
<%= @user.description.html_safe %> |
Porém, se o usuário salvar a descrição da seguinte forma
|
1 |
<script>alert('Hello');</script> |
Este script será executado na hora da renderização da sua view.
Foi utilizado um alert como exemplo, porém, os ataques podem ocorrer utilizando métodos muito mais poderosos.
Prevenção:
NUNCA UTILIZE os métodos html_safe, raw ou content_tag para exibir uma informação inserida por um usuário e caso queira proporcionar a opção de salvar textos personalizados, prefira uma ferramenta que utilize a linguagem markdown e que não permita o uso de tags HTML.
6- Http
O protocolo http faz a transmissão de dados sem utilizar criptografia e qualquer um que interceptar essa transmissão pode ter acesso livre a estes dados.
Prevenção:
Obrigue todas as requisições feitas para o servidor de produção a utilizarem o protocolo https adicionando o seguinte trecho ao arquivo config/environments/production.rb (e preparando o seu servidor).
|
1 |
config.force_ssl = true |
7- Cross-Site Request Forgery (CSRF)
Um tipo de ataque que força um usuário autenticado a executar ações indesejadas. Como quem realiza o ataque não consegue ver o resultado da resposta, estes tipos de ataque costumam ser de mudança de estado, ou seja, realizando alteração de email, transações bancárias e etc.
Prevenção:
O Ruby on Rails possui um método para proteção contra este tipo de ataque.
Para utilizá-lo vá até o arquivo app/controllers/application_controller.rb e adicione o seguinte método
|
1 2 3 4 |
class ApplicationController < ActionController::Base protect_from_forgery # restante do código end |
8- Requisições Abusivas
São requisições mal intencionados, que tentam realizar login por força bruta, ataques DDoS, etc.
Prevenção:
Utilize a gem Rack::Atack. Ela é um middleware responsável por bloquear e limitar requisições abusivas a sua aplicação web.
9- Vulnerabilidades despercebidas (falta de analise)
Todos nós estamos propensos a falhas, e algumas vulnerabilidades podem passar despercebidas.
Segurança é algo muito importante e suas falhas podem causar grandes prejuízos.
Prevenção:
Para auxílio na verificação de vulnerabilidades presentes em seu projeto Ruby on Rails, utilize a gem Brakeman. Está ferramenta fará um processo de análise e te ajudará a manter sua aplicação segura.
Conclusão
Aplicações Web possuem dados extremamente valiosos e através deste artigo você foi capaz de saber como não reproduzir algumas das principais falhas de segurança que podem estar presentes em uma aplicação Ruby on Rails.
Caso tenha interesse em conhecer mais tipos de vulnerabilidades, acesse o link para o guia de segurança do Ruby on Rails.
Se gostou, não se esqueça de compartilhar este post com seus amigos para nos ajudar a continuar produzindo material de qualidade.
Não perca nenhum conteúdo
Receba nosso resumo semanal com os novos posts, cursos, talks e vagas o/
Primeira vez no OneBitCode? Curtiu esse conteúdo?
O OneBitCode tem muito mais para você!
O OneBitCode traz conteúdos de qualidade, e em português, sobre programação com foco em Ruby on Rails e também JavaScript.
Além disso, aqui sempre levamos à você conteúdos valiosos sobre a carreira de programação, dicas sobre currículos, portfólios, perfil profissional, soft skills, enfim, tudo o que você precisa saber para continuar evoluindo como Programador(a)!
Fique por dentro de todos os conteúdos o/
Nossas redes sociais:
📹 • https://youtube.com/Onebitcode [Live todas as terças-feiras às 19h)
💻 • https://linkedin.com/company/onebitcode
🙂 • https://facebook.com/onebitcode
📱 • https://instagram.com/one_bit_code
🐦 • https://onebitcode.com/dating-apps-for-older-adults/
Nossos cursos:
🥇 • dating a sex addict
💎 • Curso Completo de Ruby
⚙ • Minicurso: API Rails 5 Completo
🐞 • Minicurso de Testes para Ruby on Rails com RSpec
Espero que curta nossos conteúdos e sempre que precisar de ajuda, fala com a gente!
Estamos aqui para você 🙂
Bem-vindo à família OneBitCode o/
No caso do Cross-Site Scripting (XSS) no caso de precisar utilizar comandos parecidos ao raw e o html_safe.
É recomendável utilizar de forma segura(no caso ñ irá rodar comandos javascripts) é o helper Sanitize.
Vale dar uma conferida nesse helper!
Muito bom, tinha muita coisa que eu não conhecia ai.