Comment empêcher les utilisateurs de Rails de s'authentifier accidentellement en tant que mauvais utilisateur?

Question

Plus précisément, j'ai écrit une application Rails dans laquelle j'utilise le magasin de session par défaut (dans Rails 2.3.5) CookieStore et j'ai repéré un problème étrange en développement. Moi-même et quelques autres utilisions le site depuis quelques semaines et nous avions chacun un login basé sur un nom d'utilisateur et un mot de passe (chaque utilisateur s'est enregistré et j'ai stocké les données (salées et hachées) dans la base de données). Je stockais l'ID utilisateur dans l'objet Rails session (et, par conséquent, dans le cookie qui est passé entre le navigateur et le serveur).

Un point important ici: puisqu'il s'agit d'un site intranet, je mets les cookies à jour jusqu'à 2 semaines pour éviter que les utilisateurs se connectent en permanence.

Aujourd'hui, je réinitialise la base de données, en effaçant tous les enregistrements utilisateur (et toutes les autres données, intentionnellement). Quelques utilisateurs ont commencé à s'enregistrer à nouveau, puis un utilisateur a constaté que la première fois qu'ils se sont rendus sur le site depuis la réinitialisation, ils étaient automatiquement connectés en tant qu'utilisateur différent!

Je pense que je peux voir pourquoi cela est arrivé: l'ID d'utilisateur passé du navigateur de cet utilisateur au serveur correspond maintenant à un autre enregistrement d'utilisateur dans ma base de données. Ma première pensée était "oh mon dieu, je ne m'attendais pas à ça!" mais plus j'y pensais, plus je réalisais que c'était probablement un comportement attendu.

Je réalise que je peux changer mon application Rails à l'utilisateur ActiveRecordStore mais avant cela, je voulais m'assurer de comprendre ce qui se passait ici. Plus précisément, est-ce que la combinaison des sessions CookieStore et du fait que les sessions restent actives pendant un certain temps crée vraiment un tel trou de sécurité? Ou est-ce que je manque quelque chose? Est-ce que le session_id devrait fournir un peu plus de sécurité ici?

Answer 1

La solution la plus simple au problème que vous avez rencontré ici serait d'avoir changé le nom du cookie lorsque vous avez réinitialisé la base de données. Le nom du cookie doit être dans config/initializers/session_store.rb

ActionController::Base.session = { 
    :key   => '_your_app_session_v2', 

Vous pouvez aussi changer le secret, mais qui peut générer des erreurs pour vos utilisateurs si elles demandent le site avec un ancien cookie.

Answer 2

Le gros trou de sécurité dans cette configuration n'est pas la longueur du cookie, c'est la définition du user_id dans un cookie. Cela signifie que toute personne qui se connecte à votre site peut se connecter comme n'importe qui d'autre simplement en changeant ce cookie! Un hacker passera juste en revue les user_id's, en se connectant et en voyant s'il y a quelque chose qu'ils veulent voler ou abuser.

Si vous voulez rouler votre propre authentification, essayez plutôt ceci: ajoutez un champ de chaîne "token" à votre table utilisateur. Lorsque quelqu'un se connecte, définissez ce jeton sur un ensemble aléatoire de chiffres et de lettres et transmettez comme en tant que cookie à l'utilisateur. Le jeton doit comporter au moins 32 caractères, alphanumériques, majuscules et minuscules.

Maintenant, lorsqu'un utilisateur accède à une page, son compte est recherché par ce hachage au lieu de son id_utilisateur. La valeur est que le hachage est beaucoup plus difficile à deviner, et ne sera jamais répété. Vos ID utilisateur ont été répétés lorsque vous avez réinitialisé la base de données, ce qui a amené les utilisateurs à se connecter les uns aux autres.

MISE À JOUR

@shingara est juste que le magasin cookie ne gère la partie de la sécurité déjà, mon erreur. Le mixage user_id est donc une occurrence unique car vous réinitialisez la base de données. Ce n'est pas un problème auquel vous serez confronté dans un environnement de production, à moins que vous ne réinitialisiez à nouveau la base de données. Si la réinitialisation est jamais une possibilité, alors encore faire la création de jetons comme je le recommandais. Sinon, vous allez bien.

Answer 3

Votre cas est arrivé seulement si vous avez 2 utilisateurs différents avec le même user_id. Donc, ce n'est pas possible si vous définissez l'user_id comme unique.

Un autre cas, vous pouvez ajouter dans la session, un hachage avec une clé unique par l'utilisateur. Lorsque vous vérifiez la session, vous obtenez le user_id et vérifiez si le user_token est identique. Sinon, l'utilisateur n'est pas autorisé.

Answer 4

Merci pour toutes les réponses. Ils ont tous répondu à ma question d'une certaine manière: oui, mon installation (et mon ne pas définir une nouvelle clé de session après avoir essuyé les utilisateurs) crée un trou de sécurité.

De nombreux tutoriels Rails préconisent cette configuration sans mentionner le fait que tout ce dont vous avez besoin est de singe avec votre cookie pour être pleinement authentifié en tant qu'un autre utilisateur.

Donc, pour résumer, je posais la question parce que je ne pouvais pas trouver quoi que ce soit discuter du danger de CookieStore séance + longues durées de vie des cookies, et je trouve surprenant donc pensé que je pourrais manquer quelque chose évidente.

Answer 5

J'ai eu un problème similaire et résolu à l'aide d'un extrait de code similaire à this comment by mdesantis on managing Rails secret token