{"id":27233,"date":"2017-10-31T14:05:41","date_gmt":"2017-10-31T14:05:41","guid":{"rendered":"https:\/\/dev.railscarma.com\/preventing-security-issues-rails\/"},"modified":"2022-09-06T09:26:04","modified_gmt":"2022-09-06T09:26:04","slug":"prevenir-les-problemes-de-securite","status":"publish","type":"post","link":"https:\/\/www.railscarma.com\/fr\/blog\/articles-techniques\/prevenir-les-problemes-de-securite\/","title":{"rendered":"Pr\u00e9venir les probl\u00e8mes de s\u00e9curit\u00e9 dans Rails"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

La s\u00e9curit\u00e9 est une pr\u00e9occupation majeure pour tout d\u00e9veloppeur aspirant \u00e0 un d\u00e9veloppement r\u00e9ussi et durable d\u2019applications web. Chaque d\u00e9veloppeur souhaite coder de mani\u00e8re \u00e0 ce que ses applications soient aussi s\u00e9curis\u00e9es que possible contre toute attaque. Cependant, aucun code 100% ne peut \u00eatre exempt de bogues ou s\u00e9curis\u00e9. Ainsi, les d\u00e9veloppeurs sont conscients qu\u2019ils doivent faire de leur mieux pour cr\u00e9er leurs applications avec un minimum de vuln\u00e9rabilit\u00e9 aux attaques. La d\u00e9tection des vuln\u00e9rabilit\u00e9s est facile, mais les failles de s\u00e9curit\u00e9 et les piratages peuvent entra\u00eener des pertes. C'est la raison pour laquelle il est toujours pr\u00e9f\u00e9rable de v\u00e9rifier les probl\u00e8mes de s\u00e9curit\u00e9 d\u00e8s le d\u00e9but du processus de d\u00e9veloppement d'une application, tout en effectuant des contr\u00f4les de qualit\u00e9 r\u00e9guliers pour garder le cap.<\/p>

1] S\u00e9ances<\/strong><\/h3>

Un bon point de d\u00e9part pour \u00e9valuer la s\u00e9curit\u00e9 est les sessions, qui peuvent \u00eatre vuln\u00e9rables \u00e0 certaines attaques.<\/p>

session[:user_id] = @current_user.id User.find(session[:user_id])<\/code><\/pre>
\u2013 Par d\u00e9faut, Ruby on Rails utilise un magasin de sessions bas\u00e9 sur les cookies. Cela implique qu'\u00e0 moins que quelque chose ne soit modifi\u00e9, la session n'expirera pas sur le serveur. Cela signifie donc que nous ne devons jamais conserver de donn\u00e9es sensibles telles que des mots de passe, des identifiants, etc. dans les sessions.
\u2013 La meilleure pratique consiste donc \u00e0 travailler avec une session bas\u00e9e sur une base de donn\u00e9es, ce qui est tr\u00e8s simple avec Rails \u2013<\/p>
Projet ::Application.config.session_store :active_record_store
L'ID de session est une cha\u00eene hexad\u00e9cimale al\u00e9atoire de 32 caract\u00e8res.<\/p>
L'ID de session est g\u00e9n\u00e9r\u00e9 \u00e0 l'aide de SecureRandom.hex qui g\u00e9n\u00e8re une cha\u00eene hexad\u00e9cimale al\u00e9atoire \u00e0 l'aide de l'une des m\u00e9thodes sp\u00e9cifiques \u00e0 la plate-forme telles que OpenSSL, \/dev\/urandom ou Win32, pour g\u00e9n\u00e9rer des nombres al\u00e9atoires cryptographiquement s\u00e9curis\u00e9s. Actuellement, il n'est pas possible d'effectuer une attaque par force brute, c'est-\u00e0-dire par essais et erreurs, sur les informations de connexion dans les identifiants de session Rails.<\/p>
Voici quelques-unes des attaques courantes bas\u00e9es sur des sessions\u00a0:
D\u00e9tournement de session\u00a0:\u00a0-\u00a0cela 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\u00a0: - En plus de voler l'ID de session d'un utilisateur, l'attaquant est \u00e9galement capable de corriger un ID de session qu'il conna\u00eet. C\u2019est ce qu\u2019on appelle la fixation de session.
Expiration de session : - Les attaquants tentent \u00e9galement d'augmenter la dur\u00e9e de l'attaque avec des sessions qui n'expirent jamais. Les attaques telles que la falsification de requ\u00eates intersites (CSRF), le d\u00e9tournement de session et la fixation de session en sont des exemples.<\/p>
2]Injection de commande<\/strong><\/h3>
Une application devient vuln\u00e9rable \u00e0 l'injection de commandes, dans le cas o\u00f9 l'attaquant est capable d'influencer les param\u00e8tres de ligne de commande ou les commandes Unix dans leur ensemble. Cependant, comme l'ex\u00e9cution de commandes UNIX dans Rails n'est pas courante, ces attaques sont moins susceptibles d'avoir lieu.
D'un autre c\u00f4t\u00e9, des vuln\u00e9rabilit\u00e9s peuvent survenir dans un processus en arri\u00e8re-plan utilisant directement les commandes Unix pour les donn\u00e9es client.<\/p>
Voici quelques-unes des m\u00e9thodes de ligne de commande Rails courantes\u00a0:
%x[\u2026]
syst\u00e8me()
ex\u00e9cutable()
`…`
Il convient \u00e9galement de noter qu\u2019il existe plusieurs fa\u00e7ons d\u2019encha\u00eener des commandes, mais cela d\u00e9pend \u00e9galement du syst\u00e8me d\u2019exploitation h\u00f4te. Exemples\u00a0: "&", "&&", "|", "||" etc.
Variables d'environnement s\u00e9curis\u00e9es lors de l'ex\u00e9cution de commandes
Les processus ex\u00e9cut\u00e9s par vos applications Rails obtiennent les variables d'environnement des processus parents qui peuvent comprendre les cl\u00e9s API, etc.<\/p>
3]Injection SQL<\/strong><\/h3>
L'injection SQL se produit lorsqu'un utilisateur est capable de manipuler une valeur utilis\u00e9e de mani\u00e8re non s\u00e9curis\u00e9e dans une requ\u00eate SQL. Cela peut entra\u00eener une perte de donn\u00e9es, des fuites de donn\u00e9es, des privil\u00e8ges \u00e9lev\u00e9s, entre autres r\u00e9sultats ind\u00e9sirables.<\/p>
L'injection SQL est une attaque tr\u00e8s simple et courante qui se produit g\u00e9n\u00e9ralement et son impact peut \u00eatre tr\u00e8s grave en fonction du site Web et de la situation dans laquelle elle se produit.<\/p>
En tant que d\u00e9veloppeurs, nous devons prendre en compte toutes les possibilit\u00e9s o\u00f9 une injection SQL peut se produire et les g\u00e9rer en cons\u00e9quence.<\/p>
Voici \u00e0 quoi ressemble l'injection SQL\u00a0:<\/p>
Employ\u00e9.all(:conditions => "d\u00e9signation = #{params[:d\u00e9signation]}")<\/code><\/pre>
Le code ci-dessus est vuln\u00e9rable \u00e0 l\u2019injection SQL, le code suivant emp\u00eachera l\u2019injection SQL.<\/p>
Employ\u00e9.all(:conditions => ['d\u00e9signation = ?', params[:d\u00e9signation]])<\/code><\/pre>
OU<\/p>
Employ\u00e9.all(:conditions => {:designation => params[:designation]})<\/code><\/pre>
Contre-mesures contre l'injection SQL dans Rails<\/strong><\/h5>
Tester chaque instruction pour l'injection SQL peut \u00eatre un travail fastidieux, mais nous devrions prendre des contre-mesures comme un scanner de code statique comme Brakeman et vous pouvez \u00e9crire des cas de tests unitaires.
a)R\u00e8gle g\u00e9n\u00e9rale :<\/strong>\u2013 N'utilisez jamais de param\u00e8tres dans l'inflexion de cha\u00eene (#{}) comme \u00e7a
Par exemple<\/p>
Utilisateur.where("name = '#{params[:name]}'")<\/code><\/pre>
b)Attention, les param\u00e8tres peuvent \u00e9galement \u00eatre un tableau, par exemple\u00a0:<\/strong><\/p>
params[:user] si vous ajoutez ?user[]=1 \u00e0 l'URL. L'utilisateur existe ? params[:user] ex\u00e9cutera alors la requ\u00eate SELECT 1 AS one FROM \u00abusers\u00bb WHERE (1) LIMIT 1.<\/p>
4] Scripts intersites (XSS)<\/strong><\/h3>
Avec l'aide de XSS, un attaquant peut ex\u00e9cuter des scripts dans le contexte de s\u00e9curit\u00e9 de votre application Web.<\/p>
Consid\u00e9rez cet extrait de vue Rails\u00a0: <%= @flat.title %>. Si le titre de l'appartement est modifi\u00e9 avec l'ajout du HTML, cette vue Rails restitue ce HTML dans le contexte de s\u00e9curit\u00e9 de l'application. Ainsi, le navigateur ex\u00e9cuterait le HTML, qui est XSS.<\/p>
En fait, cela ne fonctionne pas encore dans Rails de nos jours, dans la version 2 de Rails, vous devrez \u00e9chapper \u00e0 chaque entr\u00e9e utilisateur\u00a0: <%= h(@flat.title) %>
De nos jours, Rails est livr\u00e9 avec un indicateur sur chaque cha\u00eene qui la marque comme HTML, qu'elle soit s\u00fbre ou non\u00a0: @flat.title.html_safe?. Dans le cas o\u00f9 il n'est pas s\u00e9curis\u00e9 (par exemple depuis un param\u00e8tre, depuis la base de donn\u00e9es, \u2026) il sera automatiquement \u00e9chapp\u00e9 lors de son utilisation de cette mani\u00e8re\u00a0: <%= @flat.title %>
Dans Rails 3.0, la protection contre XSS est un comportement par d\u00e9faut.<\/p>
Contre-mesures<\/strong><\/h3>
a) Une strat\u00e9gie de politique de s\u00e9curit\u00e9 du contenu (CSP)<\/strong><\/p>
Une s\u00e9curit\u00e9 du contenu Politique<\/a> se pr\u00e9sente essentiellement sous la forme d'un en-t\u00eate HTTP et cela fait une d\u00e9claration des r\u00e8gles sur ce que toutes les sources sont autoris\u00e9es pour tous types d'actifs. En cons\u00e9quence du respect de ces r\u00e8gles, tout le reste est interdit. Une fois impl\u00e9ment\u00e9 correctement, il est capable d\u2019\u00e9liminer toutes les vuln\u00e9rabilit\u00e9s Cross-Site-Scripting (XSS) de votre application.<\/p>
b) HTML-Safe, ActiveSupport :: SafeBuffer<\/strong><\/p>
Le module ActiveSupport::SafeBuffer a \u00e9t\u00e9 introduit par Rails 3 pour ajouter un indicateur HTML-safe aux cha\u00eenes. Par d\u00e9faut, c'est faux, surtout lorsque la cha\u00eene a une source externe telle que la base de donn\u00e9es ou les param\u00e8tres. Le drapeau est renvoy\u00e9 avec \u00ab\u00a0string\u00a0\u00bb.html_safe?.<\/p>
La m\u00e9thode d'\u00e9chappement HTML h() \u00e9chappe \u00e0 la cha\u00eene marquant une cha\u00eene comme \u00e9tant s\u00e9curis\u00e9e pour HTML.<\/p>
h("html>").html_safe? #=> vrai ("html>").html_safe ? #=>faux<\/code><\/pre>
c) Pr\u00e9vention XSS OWASP (Open Web Application Security Project)<\/strong><\/p>
Pour la pr\u00e9vention du XSS, toutes les donn\u00e9es non fiables doivent \u00eatre refus\u00e9es et emp\u00each\u00e9es d'\u00eatre plac\u00e9es directement dans le HTML ou tout autre contexte (comme JavaScript, CSS, les contextes d'attribut).<\/p>
d) Protection XSS dans les mod\u00e8les HAML<\/strong><\/p>
Lors de l'utilisation des mod\u00e8les Haml, au lieu d'ERB, les cha\u00eenes sont automatiquement \u00e9chapp\u00e9es de la m\u00eame mani\u00e8re que dans les mod\u00e8les ERB. Et de la m\u00eame mani\u00e8re qu'avec les mod\u00e8les ERB, les cha\u00eenes HTML s\u00e9curis\u00e9es (string.html_safe? renvoie true) ne sont pas automatiquement ignor\u00e9es. La notation != dans Haml fonctionne de la m\u00eame mani\u00e8re que <%= raw(\u2026) %> fonctionne dans ERB, elle restitue donc la version sans \u00e9chappement.
Par d\u00e9faut,<\/p>
=" soulign\u00e9 " != " soulign\u00e9 "<\/em><\/em><\/em><\/em><\/code><\/pre>
compile pour\u00a0:<\/p>
soulign\u00e9<\/em> soulign\u00e9<\/em><\/code><\/pre>
Il faut donc faire attention lors de l'utilisation de != dans Haml et s'assurer qu'aucune donn\u00e9e utilisateur n'est rendue sans \u00e9chappement.
Voici quelques mesures pr\u00e9ventives qui peuvent \u00eatre prises lors du d\u00e9veloppement d\u2019une application ferroviaire.<\/p>
1] Authentification<\/strong><\/h5>
Utilisez l'appareil ou la gemme Authlogic.
\u2013 Pour activer l'authentification, n'oubliez pas d'ajouter -><\/p>
classe ProjectController <ApplicationController
avant_filter\u00a0:authenticate_user
\u2013 Par d\u00e9faut, Devise ne n\u00e9cessite que 6 caract\u00e8res pour un mot de passe. Le minimum peut \u00eatre modifi\u00e9 dans\u00a0: \/config\/initializers\/devise.rb
config.password_length = 8..128
\u2013 Vous pouvez modifier la complexit\u00e9 du mot de passe en ajoutant le code suivant dans le mod\u00e8le utilisateur.<\/p>
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<\/code><\/pre>
2] R\u00e9f\u00e9rence d'objet directe non s\u00e9curis\u00e9e ou navigation forc\u00e9e<\/strong><\/h5>
\u2013 Les applications Ruby on Rails utilisent une structure d'URL reposante, rendant les chemins utilis\u00e9s principalement devinables et intuitifs. Ainsi, afin de se prot\u00e9ger contre un utilisateur tentant d\u2019acc\u00e9der ou de modifier des donn\u00e9es appartenant \u00e0 un autre utilisateur, les actions doivent \u00eatre sp\u00e9cifiquement contr\u00f4l\u00e9es. Il n\u2019existe pas de protection int\u00e9gr\u00e9e de ce type sur une application Vanilla Rails. De plus, cela peut \u00eatre effectu\u00e9 manuellement au niveau du contr\u00f4leur.
\u2013 Utilisez cancancan ou pandit pour le contr\u00f4le d\u2019acc\u00e8s<\/p>
3] Affectation de masse et param\u00e8tres forts<\/strong><\/h5>
- projet de classe < ActiveRecord::Base attr_accessible :name, :admin end<\/code><\/pre>
Selon l'exemple ci-dessus, avec l'attribut admin accessible, les \u00e9l\u00e9ments suivants pourraient fonctionner\u00a0:
\u2013 curl -d \u00ab project[name]=triage&project[admin]=1 \u00bb h\u00f4te:port\/projets
\u2013 config.active_record.whitelist_attributes = vrai<\/p>
4] Redirections et transferts<\/strong><\/h5>
\u2013 Il est conseill\u00e9 d\u2019\u00e9viter d\u2019utiliser les redirections qui utilisent des param\u00e8tres
Par exemple\u00a0:\u00a0- \/\/www.example.com\/redirect?url=\/\/www.example_commerce_site.com\/checkout
\u2013 une protection restrictive consiste \u00e0 utiliser le :only_path<\/p>
commencer si chemin = URI.parse(params[:url]).path redirect_to chemin de fin de sauvetage URI::InvalidURIError redirect_to '\/' end<\/code><\/pre>
\u2013 Ayez un hachage des sites approuv\u00e9s et autorisez uniquement ceux-ci \u00e0 \u00eatre redirig\u00e9s.<\/p>
5] Chemins de rendu dynamiques<\/strong><\/h5>
\u2013 Des pr\u00e9cautions doivent \u00eatre prises lorsque vous effectuez le rendu dynamique d\u2019une vue en fonction de certaines conditions. Cela pourrait entra\u00eener le chargement de la vue administrateur.<\/p>
6] Partage de ressources entre origines<\/strong><\/h5>
\u2013 Comme le t\u00e9l\u00e9chargement de fichiers.
\u2013 Le site de r\u00e9ception doit restreindre et autoriser uniquement les domaines sur liste blanche et s'assurer que les demandes proviennent \u00e9galement de ces domaines uniquement.
\u2013 D\u00e9finissez \u00e9galement l\u2019en-t\u00eate Access-Control-Allow-Origin \u00e0 la fois dans la r\u00e9ponse \u00e0 la demande OPTIONS et \u00e0 la demande POST. En effet, la requ\u00eate OPTIONS est envoy\u00e9e en premier, afin de d\u00e9terminer si le site distant ou r\u00e9cepteur autorise le domaine demandeur.
\u2013 Une requ\u00eate POST est envoy\u00e9e. Encore une fois, l'en-t\u00eate doit \u00eatre d\u00e9fini pour que la transaction soit affich\u00e9e comme r\u00e9ussie.<\/p>
7] Bogues de logique m\u00e9tier<\/strong><\/h5>
\u2013 Les applications, quelle que soit la technologie sur laquelle elles sont bas\u00e9es, peuvent comporter des erreurs de logique m\u00e9tier susceptibles de conduire \u00e0 des bogues de s\u00e9curit\u00e9. Il peut \u00eatre tr\u00e8s difficile de d\u00e9tecter de tels bugs de s\u00e9curit\u00e9 \u00e0 l\u2019aide des outils automatis\u00e9s. Des pratiques telles que la r\u00e9vision r\u00e9guli\u00e8re des codes, la programmation en bin\u00f4me et l'\u00e9criture de tests unitaires peuvent vous aider \u00e0 mieux \u00e9viter l'apparition de tels bogues de s\u00e9curit\u00e9.<\/p>
8] Fichiers sensibles<\/strong><\/h5>
Voici quelques fichiers dont nous devons prendre soin lors du d\u00e9veloppement d\u2019une application Web.
\/config\/database.yml- Peut contenir des informations d'identification de production.
\/config\/initializers\/secret_token.rb \u2013 Contient un secret utilis\u00e9 pour hacher le cookie de session.
\/db\/seeds.rb \u2013 Peut contenir des donn\u00e9es de d\u00e9part, y compris l'utilisateur administrateur d'amor\u00e7age.
\/db\/development.sqlite3 \u2013 Peut contenir des donn\u00e9es r\u00e9elles.<\/p>
9] Chiffrement<\/strong><\/h5>
Ruby on Rails utilise le cryptage du syst\u00e8me d'exploitation. Vous ne devriez presque jamais \u00e9crire vos propres solutions de chiffrement.
Mettre \u00e0 jour les rails et disposer d'un processus de mise \u00e0 jour des d\u00e9pendances.<\/p>
Outils pour d\u00e9tecter les probl\u00e8mes de s\u00e9curit\u00e9 dans l'application Rails<\/strong><\/h4>
  • Serre-frein<\/li>
  • audit du bundler<\/li>
  • Codecode ::Aube<\/li>
  • Rack::Attaque<\/li>
  • Tarentule<\/li>
  • Ceinture \u00e0 outils Hakiri<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t
    Abonnez-vous pour les derni\u00e8res mises \u00e0 jour<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t
    \t\t\t\t\t