Prévenir les problèmes de sécurité dans Rails

La sécurité est une préoccupation majeure pour tout développeur aspirant à un développement réussi et durable d’applications web. Chaque développeur souhaite coder de manière à ce que ses applications soient aussi sécurisées que possible contre toute attaque. Cependant, aucun code 100% ne peut être exempt de bogues ou sécurisé. Ainsi, les développeurs sont conscients qu’ils doivent faire de leur mieux pour créer leurs applications avec un minimum de vulnérabilité aux attaques. La détection des vulnérabilités est facile, mais les failles de sécurité et les piratages peuvent entraîner des pertes. C'est la raison pour laquelle il est toujours préférable de vérifier les problèmes de sécurité dès le début du processus de développement d'une application, tout en effectuant des contrôles de qualité réguliers pour garder le cap.

1] Séances

Un bon point de départ pour évaluer la sécurité est les sessions, qui peuvent être vulnérables à certaines attaques.

session[:user_id] = @current_user.id User.find(session[:user_id])

– Par défaut, Ruby on Rails utilise un magasin de sessions basé sur les cookies. Cela implique qu'à moins que quelque chose ne soit modifié, la session n'expirera pas sur le serveur. Cela signifie donc que nous ne devons jamais conserver de données sensibles telles que des mots de passe, des identifiants, etc. dans les sessions.
– La meilleure pratique consiste donc à travailler avec une session basée sur une base de données, ce qui est très simple avec Rails –

Projet ::Application.config.session_store :active_record_store
L'ID de session est une chaîne hexadécimale aléatoire de 32 caractères.

L'ID de session est généré à l'aide de SecureRandom.hex qui génère une chaîne hexadécimale aléatoire à l'aide de l'une des méthodes spécifiques à la plate-forme telles que OpenSSL, /dev/urandom ou Win32, pour générer des nombres aléatoires cryptographiquement sécurisés. Actuellement, il n'est pas possible d'effectuer une attaque par force brute, c'est-à-dire par essais et erreurs, sur les informations de connexion dans les identifiants de session Rails.

Voici quelques-unes des attaques courantes basées sur des sessions :
Détournement de session : - cela permet aux attaquants de voler l'identifiant de session d'un utilisateur et d'utiliser l'application Web au nom de la victime.
Correction de session : - En plus de voler l'ID de session d'un utilisateur, l'attaquant est également capable de corriger un ID de session qu'il connaît. C’est ce qu’on appelle la fixation de session.
Expiration de session : - Les attaquants tentent également d'augmenter la durée de l'attaque avec des sessions qui n'expirent jamais. Les attaques telles que la falsification de requêtes intersites (CSRF), le détournement de session et la fixation de session en sont des exemples.

2]Injection de commande

Une application devient vulnérable à l'injection de commandes, dans le cas où l'attaquant est capable d'influencer les paramètres de ligne de commande ou les commandes Unix dans leur ensemble. Cependant, comme l'exécution de commandes UNIX dans Rails n'est pas courante, ces attaques sont moins susceptibles d'avoir lieu.
D'un autre côté, des vulnérabilités peuvent survenir dans un processus en arrière-plan utilisant directement les commandes Unix pour les données client.

Voici quelques-unes des méthodes de ligne de commande Rails courantes :
%x[…]
système()
exécutable()
`…`
Il convient également de noter qu’il existe plusieurs façons d’enchaîner des commandes, mais cela dépend également du système d’exploitation hôte. Exemples : "&", "&&", "|", "||" etc.
Variables d'environnement sécurisées lors de l'exécution de commandes
Les processus exécutés par vos applications Rails obtiennent les variables d'environnement des processus parents qui peuvent comprendre les clés API, etc.

3]Injection SQL

L'injection SQL se produit lorsqu'un utilisateur est capable de manipuler une valeur utilisée de manière non sécurisée dans une requête SQL. Cela peut entraîner une perte de données, des fuites de données, des privilèges élevés, entre autres résultats indésirables.

L'injection SQL est une attaque très simple et courante qui se produit généralement et son impact peut être très grave en fonction du site Web et de la situation dans laquelle elle se produit.

En tant que développeurs, nous devons prendre en compte toutes les possibilités où une injection SQL peut se produire et les gérer en conséquence.

Voici à quoi ressemble l'injection SQL :

Employé.all(:conditions => "désignation = #{params[:désignation]}")

Le code ci-dessus est vulnérable à l’injection SQL, le code suivant empêchera l’injection SQL.

Employé.all(:conditions => ['désignation = ?', params[:désignation]])

OU

Employé.all(:conditions => {:designation => params[:designation]})

Contre-mesures contre l'injection SQL dans Rails

Tester chaque instruction pour l'injection SQL peut être un travail fastidieux, mais nous devrions prendre des contre-mesures comme un scanner de code statique comme Brakeman et vous pouvez écrire des cas de tests unitaires.
a)Règle générale :– N'utilisez jamais de paramètres dans l'inflexion de chaîne (#{}) comme ça
Par exemple

Utilisateur.where("name = '#{params[:name]}'")

b)Attention, les paramètres peuvent également être un tableau, par exemple :

params[:user] si vous ajoutez ?user[]=1 à l'URL. L'utilisateur existe ? params[:user] exécutera alors la requête SELECT 1 AS one FROM «users» WHERE (1) LIMIT 1.

4] Scripts intersites (XSS)

Avec l'aide de XSS, un attaquant peut exécuter des scripts dans le contexte de sécurité de votre application Web.

Considérez cet extrait de vue Rails : <%= @flat.title %>. Si le titre de l'appartement est modifié avec l'ajout du HTML, cette vue Rails restitue ce HTML dans le contexte de sécurité de l'application. Ainsi, le navigateur exécuterait le HTML, qui est XSS.

En fait, cela ne fonctionne pas encore dans Rails de nos jours, dans la version 2 de Rails, vous devrez échapper à chaque entrée utilisateur : <%= h(@flat.title) %>
De nos jours, Rails est livré avec un indicateur sur chaque chaîne qui la marque comme HTML, qu'elle soit sûre ou non : @flat.title.html_safe?. Dans le cas où il n'est pas sécurisé (par exemple depuis un paramètre, depuis la base de données, …) il sera automatiquement échappé lors de son utilisation de cette manière : <%= @flat.title %>
Dans Rails 3.0, la protection contre XSS est un comportement par défaut.

Contre-mesures

a) Une stratégie de politique de sécurité du contenu (CSP)

Une sécurité du contenu Politique se présente essentiellement sous la forme d'un en-tête HTTP et cela fait une déclaration des règles sur ce que toutes les sources sont autorisées pour tous types d'actifs. En conséquence du respect de ces règles, tout le reste est interdit. Une fois implémenté correctement, il est capable d’éliminer toutes les vulnérabilités Cross-Site-Scripting (XSS) de votre application.

b) HTML-Safe, ActiveSupport :: SafeBuffer

Le module ActiveSupport::SafeBuffer a été introduit par Rails 3 pour ajouter un indicateur HTML-safe aux chaînes. Par défaut, c'est faux, surtout lorsque la chaîne a une source externe telle que la base de données ou les paramètres. Le drapeau est renvoyé avec « string ».html_safe?.

La méthode d'échappement HTML h() échappe à la chaîne marquant une chaîne comme étant sécurisée pour HTML.

h("html>").html_safe? #=> vrai ("html>").html_safe ? #=>faux

c) Prévention XSS OWASP (Open Web Application Security Project)

Pour la prévention du XSS, toutes les données non fiables doivent être refusées et empêchées d'être placées directement dans le HTML ou tout autre contexte (comme JavaScript, CSS, les contextes d'attribut).

d) Protection XSS dans les modèles HAML

Lors de l'utilisation des modèles Haml, au lieu d'ERB, les chaînes sont automatiquement échappées de la même manière que dans les modèles ERB. Et de la même manière qu'avec les modèles ERB, les chaînes HTML sécurisées (string.html_safe? renvoie true) ne sont pas automatiquement ignorées. La notation != dans Haml fonctionne de la même manière que <%= raw(…) %> fonctionne dans ERB, elle restitue donc la version sans échappement.
Par défaut,

=" souligné " != " souligné "

compile pour :

souligné souligné

Il faut donc faire attention lors de l'utilisation de != dans Haml et s'assurer qu'aucune donnée utilisateur n'est rendue sans échappement.
Voici quelques mesures préventives qui peuvent être prises lors du développement d’une application ferroviaire.

1] Authentification

Utilisez l'appareil ou la gemme Authlogic.
– Pour activer l'authentification, n'oubliez pas d'ajouter ->

classe ProjectController <ApplicationController
avant_filter :authenticate_user
– Par défaut, Devise ne nécessite que 6 caractères pour un mot de passe. Le minimum peut être modifié dans : /config/initializers/devise.rb
config.password_length = 8..128
– Vous pouvez modifier la complexité du mot de passe en ajoutant le code suivant dans le modèle utilisateur.

valider :password_complexity def password_complexity si password.present ? et non password.match(/\A(?=.*[az])(?=.*[AZ])(?=.*\d).+\z/) error.add :password, "doit inclure au moins une lettre minuscule, une lettre majuscule et un chiffre" fin fin

2] Référence d'objet directe non sécurisée ou navigation forcée

– Les applications Ruby on Rails utilisent une structure d'URL reposante, rendant les chemins utilisés principalement devinables et intuitifs. Ainsi, afin de se protéger contre un utilisateur tentant d’accéder ou de modifier des données appartenant à un autre utilisateur, les actions doivent être spécifiquement contrôlées. Il n’existe pas de protection intégrée de ce type sur une application Vanilla Rails. De plus, cela peut être effectué manuellement au niveau du contrôleur.
– Utilisez cancancan ou pandit pour le contrôle d’accès

3] Affectation de masse et paramètres forts

- projet de classe < ActiveRecord::Base attr_accessible :name, :admin end

Selon l'exemple ci-dessus, avec l'attribut admin accessible, les éléments suivants pourraient fonctionner :
– curl -d « project[name]=triage&project[admin]=1 » hôte:port/projets
– config.active_record.whitelist_attributes = vrai

4] Redirections et transferts

– Il est conseillé d’éviter d’utiliser les redirections qui utilisent des paramètres
Par exemple : - //www.example.com/redirect?url=//www.example_commerce_site.com/checkout
– une protection restrictive consiste à utiliser le :only_path

commencer si chemin = URI.parse(params[:url]).path redirect_to chemin de fin de sauvetage URI::InvalidURIError redirect_to '/' end

– Ayez un hachage des sites approuvés et autorisez uniquement ceux-ci à être redirigés.

5] Chemins de rendu dynamiques

– Des précautions doivent être prises lorsque vous effectuez le rendu dynamique d’une vue en fonction de certaines conditions. Cela pourrait entraîner le chargement de la vue administrateur.

6] Partage de ressources entre origines

– Comme le téléchargement de fichiers.
– Le site de réception doit restreindre et autoriser uniquement les domaines sur liste blanche et s'assurer que les demandes proviennent également de ces domaines uniquement.
– Définissez également l’en-tête Access-Control-Allow-Origin à la fois dans la réponse à la demande OPTIONS et à la demande POST. En effet, la requête OPTIONS est envoyée en premier, afin de déterminer si le site distant ou récepteur autorise le domaine demandeur.
– Une requête POST est envoyée. Encore une fois, l'en-tête doit être défini pour que la transaction soit affichée comme réussie.

7] Bogues de logique métier

– Les applications, quelle que soit la technologie sur laquelle elles sont basées, peuvent comporter des erreurs de logique métier susceptibles de conduire à des bogues de sécurité. Il peut être très difficile de détecter de tels bugs de sécurité à l’aide des outils automatisés. Des pratiques telles que la révision régulière des codes, la programmation en binôme et l'écriture de tests unitaires peuvent vous aider à mieux éviter l'apparition de tels bogues de sécurité.

8] Fichiers sensibles

Voici quelques fichiers dont nous devons prendre soin lors du développement d’une application Web.
/config/database.yml- Peut contenir des informations d'identification de production.
/config/initializers/secret_token.rb – Contient un secret utilisé pour hacher le cookie de session.
/db/seeds.rb – Peut contenir des données de départ, y compris l'utilisateur administrateur d'amorçage.
/db/development.sqlite3 – Peut contenir des données réelles.

9] Chiffrement

Ruby on Rails utilise le cryptage du système d'exploitation. Vous ne devriez presque jamais écrire vos propres solutions de chiffrement.
Mettre à jour les rails et disposer d'un processus de mise à jour des dépendances.

Outils pour détecter les problèmes de sécurité dans l'application Rails

• Serre-frein
• audit du bundler
• Codecode ::Aube
• Rack::Attaque
• Tarentule
• Ceinture à outils Hakiri