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])

– By default, Ruby on Rails uses a Cookie-based session store. This implies that unless something is changed, the session will not expire on the server. So, it means that we should never keep sensitive data such as passwords and IDs etc in sessions.
– The best practice therefore, is to work with a database based session, which is very easy with 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.

The session ID is generated using SecureRandom.hex which generates a random hexadecimal string using any of the platform-specific methods such as OpenSSL, /dev/urandom or Win32, for generating cryptographically secure random numbers. Currently, it is not possible to brute-force i.e trial and error attack on login credentials in Rails’ session Ids.

Voici quelques-unes des attaques courantes basées sur des sessions :
Session Hijacking:- This allows the attackers to steal a user’s session ID and use the web application in the victim’s name.
Session Fixation:- Apart from stealing a user’s session ID, the attacker is also capable of fixing a session ID known to them. This is called as session fixation.
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()
`…`
It should also be noted that there are more than one ways how to chain commands together, but that also depends on the hosting operating system. Examples: “&”, “&&”, “|”, “||” 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 :– Never use params in string inflection (#{}) like so
Par exemple

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

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

params[:user] if you add ?user[]=1 to the URL. User.exists? params[:user] will then run the query 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.
– To enable auth please dont forget to add ->

classe ProjectController <ApplicationController
avant_filter :authenticate_user
– By default Devise requires only  6 characters for a password. The minimum can be changed in: /config/initializers/devise.rb
config.password_length = 8..128
– You can change the password complexity by adding the following code in user model.

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

– Ruby on Rails apps make use of a restful URL structure making the paths used mostly guessable and intuitive. So, in order to protect against a user trying to access or modify data that belongs to another user, the actions need to be specifically controlled. There is no such built-in kind of a protection out of t he gate on a vanilla Rails application. Further, it can be performed manually at the controller level.
– Use cancancan or pandit for access control

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” host:port/projects
– config.active_record.whitelist_attributes = true

4] Redirections et transferts

– It is advisable to avoid using the redirects that use parameters
Par exemple : - //www.example.com/redirect?url=//www.example_commerce_site.com/checkout
– restrictive protection is to use the :only_path

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

– Have hash of approved sites and allow only them to get redirected.

5] Chemins de rendu dynamiques

– Care should be taken when you are dynamically rendering any view based on some condition. It might result in loading admin view.

6] Partage de ressources entre origines

– Like file upload.
– The receiving site should restrict and allow only whitelisted domains and make sure that requests are also coming from those domains only.
– Also set the Access-Control-Allow-Origin header in both the response to the OPTIONS request and POST request. This is because the OPTIONS request is sent first, in order to determine if the remote or receiving site allows the requesting domain.
– A POST request, is sent. Once again, the header must be set in order for the transaction to be shown as successful.

7] Bogues de logique métier

– The applications regardless of the technology they are based on, can comprise of business logic errors that are prone to lead to security bugs. It can be really tricky to detect such security bugs using the automated tools. The practices such as regular reviews of the codes, pair programming and writing unit tests can help you best avoid such security bugs to arise.

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 – Contains a secret used to hash session cookie.
/db/seeds.rb – May contain seed data including bootstrap admin user.
/db/development.sqlite3 – May contain real data.

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