¿Cómo protege Discourse contra inyecciones SQL a través del user agent?

Noté que Discourse persiste el agente de usuario en algunas tablas, por ejemplo, web_crawler_requests. Se sabe que los atacantes utilizan el campo “user-agent” para inyectar código malicioso, como en los ataques Sleepy User Agent. Me pregunto si Discourse tiene alguna medida implementada para protegerse contra este tipo de ataques.

Discourse es una aplicación de Rails, por lo que aprovechamos las protecciones del framework en nuestro proyecto:

6 Me gusta

Hola @mbaker341997

La guía de seguridad de Rails es una buena visión general, pero en mi opinión, no cubre adecuadamente lo que muchos consideran (posiblemente) el control más importante para mitigar los ataques de inyección SQL.

La primera línea de defensa contra la “inyección SQL” es una validación sólida de los datos de entrada.

Permíteme darte un ejemplo directo de la guía de seguridad de Rails (arriba);

La guía de seguridad de Rails muestra este ejemplo simple:

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

que puede ser explotado inyectando en los parámetros de entrada:

' OR 1=1'

Sin embargo, esto se puede prevenir mediante una validación sólida en el modelo, por ejemplo:

before_validation :filter_name_param

private

def filter_name_param

   ###  tu código personalizado de filtrado de parámetros aquí para asegurar que los caracteres especiales y otro "código peligroso"
   ###  no se permitan cerca de la base de datos

end

Rails tiene muchas validaciones “listas para usar” que pueden (y deben) incluirse en los modelos para asegurar que los parámetros de entrada se validen mucho antes de tener la oportunidad de entrar en la BD.

Aquí hay más información sobre la validación en Rails:

Mucha gente olvida que las validaciones de datos de entrada son la primera línea de defensa contra los ataques de inyección SQL, y esto es cierto para todo el código web del lado del servidor como Ruby, PHP, Python, etc. En general, la validación del lado del cliente puede ser explotada y también debe validarse en el lado del servidor.

En particular, recomiendo leer la sección “Validaciones personalizadas”:

Espero que esto ayude.

2 Me gusta