Comment Discourse se protège-t-il contre les injections SQL via l'agent utilisateur ?

Contribuer Fonctionnalité
1

J’ai remarqué que Discourse persiste l’agent utilisateur dans certaines tables, comme web_crawler_requests, par exemple. On sait que des attaquants exploitent le champ « user-agent » pour injecter du code malveillant, comme dans les attaques de type Sleepy User Agent. Je me demandais si Discourse a mis en place des mesures pour se prémunir contre ce genre d’attaques ?

2

Discourse est une application Rails, nous tirons donc parti des protections du framework dans notre projet :

6 « J'aime »
3

Bonjour @mbaker341997,

Le guide de sécurité de Rails constitue une bonne vue d’ensemble, mais à mon avis, il ne couvre pas adéquatement ce que beaucoup considèrent (à juste titre) comme le contrôle le plus important pour atténuer les attaques par injection SQL.

La première ligne de défense contre l’injection SQL est une validation robuste des données d’entrée.

Laissez-moi vous donner un exemple direct tiré du guide de sécurité de Rails (ci-dessus) :

Le guide de sécurité de Rails présente cet exemple simple :

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

qui peut être exploité en injectant dans les paramètres d’entrée :

' OR 1=1'

Cependant, cela peut être évité en mettant en place une validation stricte au niveau du modèle, par exemple :

before_validation :filter_name_param

private

def filter_name_param

   ###  votre code de filtrage personnalisé des paramètres ici pour garantir que les caractères spéciaux et autres « code dangereux »
   ###  ne soient jamais autorisés à proximité de la base de données

end

Rails propose de nombreuses validations « prêtes à l’emploi » qui peuvent (et devraient) être incluses dans les modèles pour s’assurer que les paramètres d’entrée sont validés bien avant qu’ils n’aient la moindre chance d’entrer dans la base de données.

Voici plus d’informations sur les validations de Rails :

Beaucoup oublient que les validations des données d’entrée constituent la première ligne de défense contre les attaques par injection SQL, et cela vaut pour tout le code web côté serveur comme Ruby, PHP, Python, etc. De manière générale, la validation côté client peut être contournée et doit également être vérifiée côté serveur.

En particulier, je recommande de lire la section « Validations personnalisées » :

J’espère que cela vous sera utile.

2 « J'aime »