Como o Discourse se protege contra injeções de SQL através do user agent?

Contribuir Funcionalidade
1

Notei que o Discourse persiste o user agent em algumas tabelas, como a web_crawler_requests, por exemplo. Sabe-se que atacantes usam o campo “user-agent” para injetar código malicioso, como nos ataques Sleepy User Agent. Fiquei me perguntando se o Discourse tem alguma medida em vigor para se proteger contra esse tipo de ataque?

2

Discourse é uma aplicação Rails, então aproveitamos as proteções do framework em nosso projeto:

6 curtidas
3

Olá @mbaker341997

O guia de segurança do Rails é uma boa visão geral, mas, na minha opinião, ele não cobre adequadamente o que muitos consideram (discutivelmente) o controle mais importante para mitigar ataques de injeção de SQL.

A primeira linha de defesa contra “injeção de SQL” é uma validação forte dos dados de entrada.

Vou dar um exemplo direto do guia de segurança do Rails (acima);

O guia de segurança do Rails mostra este exemplo simples:

Project.find(:all, :conditions => "name = '#{params[:name]}'")

que pode ser explorado injetando nos parâmetros de entrada:

' OR 1=1'

No entanto, isso pode ser evitado com uma validação forte no modelo, por exemplo:

before_validation :filter_name_param

private

def filter_name_param

   ###  seu código de filtro de parâmetros personalizado aqui para garantir que caracteres especiais e outro "código perigoso"
   ###  não sejam permitidos em lugar nenhum perto do banco de dados

end

O Rails possui muitas validações “prontas para uso” que podem (e devem) ser incluídas nos modelos para garantir que os parâmetros de entrada sejam validados muito antes de terem a chance de entrar no banco de dados.

Aqui está mais sobre validação no Rails:

Muitas pessoas esquecem que as validações de dados de entrada são a primeira linha de defesa contra ataques de injeção de SQL, e isso é verdade para todo código de desenvolvimento web do lado do servidor, como Ruby, PHP, Python, etc. De modo geral, a validação do lado do cliente pode ser explorada e também deve ser validada no lado do servidor.

Em particular, recomendo ler a seção “Validações Personalizadas”:

Espero que ajude.

2 curtidas