J'essaie d'implémenter une protection sécurisée de CSRF au formulaire de connexion HTML, Je sais que la meilleure façon de mettre en œuvre la protection de la CSRF stocke une session CSRF_Key aléatoire dans une session, Mais je veux ajouter CSRF à mes formulaires de connexion et d'enregistrement ... et je ne veux pas stocker de nombreuses sessions pour des utilisateurs non enregistrés anonymes ...
Donc, je souhaite créer le meilleur poibble sécurisé sans utiliser des sessions ou de la base de données, avec uniquement un champ masqué / cookie, et après la connexion, je utiliserai des sessions CSRF Protection.
Mon idée d'user_storage sécurisé uniquement CSRF:
CSRF_Token = AES (IP + UserAgent + Timeestamp + Random_Data, CSRF_AES_SITE_KEY)
Lorsque csrf_aes_site_key est codé dur dans le fichier de configuration. et après chaque identifiant / enregistrement, je déchiffrera la chaîne d'AES + Velidate que l'IP & UA correspond à la demande IP & UA, et l'horodatage n'est pas trop égal à l'avance, laissez 5 min (si CSRF_TMESTAMP + 18000> = actuel_ts), et Random_Data est juste aléatoire. (et assurez-vous que le même utilisateur n'obtiendra pas le même CSRF_Token si demandé plusieurs fois dans le même TS) ...
Alors ... est-ce assez sécurisé, est-ce une bonne solution? Sinon, aucune autre suggestion pour résoudre ce dilemme? merci
Exemple complet:
https://github.com/itaarbel/aes_based_csrf_protection
numéro 1:
L'utilisateur peut prendre le CSRF_Token et soumettre au formulaire avec succès en utilisant le même jeton pour le prochain 5min
punaise? Qu'est-ce que je me soucie si l'utilisateur soumettez plusieurs fois? Tant que ce n'est pas une attaque CSRF ...
numéro 2:
Si la page est laissée ouverte pendant 5 minutes, l'utilisateur va échouer.
(page de connexion INDASH Automaticaly tous les 5 min? Maby le changer à 1h?)
Pouvez-vous repérer un risque de sécurité spécifique avec cette implémentation? ou puis-je supposer qu'il s'agit d'une manière sécurisée de la protection de la CSRF?
3 Réponses :
La méthode avec le stockage du jeton CSRF dans Cookie est assez largement utilisée ( angularjs , django ) mais cela fonctionne un peu différemment. Le serveur envoie le jeton dans cookie , le client utilise JavaScript pour lire le cookie et reflect le jeton dans un en-tête HTTP . Le serveur ne doit vérifier que la valeur de l'en-tête HTTP, même si le cookie sera également envoyé automatiquement.
Les noms de cookie et d'en-tête réels ne sont pas importants dès que JavaScript Fountend et Backend en sont conscients.
Ceci empêche le CSRF car seul JavaScript fonctionne à partir de l'origine authentique pourra lire le cookie (voir L'avantage principal est que cette approche (contrairement à celle-ci avec jeton dans les champs de formulaire) fonctionne avec des applications basées sur une seule page, dans laquelle vous ne générez pas le code HTML sur le serveur et que vous ne pouvez pas vraiment intégrer le jeton CSRF dans leur code.
Vous écrivez: "Le jeton peut être un hmac de la session Cookie". Donc, vous supposez qu'il y a un cookie de session. Je pensais que tout le point de la solution proposée de l'OP était qu'il ne devrait y avoir aucun stockage côté serveur. Lorsqu'une session (avec un cookie) a été démarrée, cela signifie que l'état est gardé côté serveur.
Cela fonctionnera pour la plupart des clients - mais échouera horriblement où le client accède à votre site via des proxies équilibrés de charge (l'adresse IP du client que vous voyez avec le changement). Une solution plus correcte utiliserait les données d'organisation de l'enregistrement WHOIS ou du numéro de l'ASN, mais il y a une dépense dans la recherche de ceux-ci - en fonction du volume de trafic utilisant simplement les Forst 16 bits de l'adresse (IPv4) suffisamment. < / p>
Vous pouvez également rencontrer des problèmes en fonction de la quantité de l'agent utilisateur que vous stockez (Google Chrome peut se mettre à jour à la volée).
semble très précaire pour moi. Ne pas utiliser cela. Les formulaires de connexion et les formulaires d'inscription ont besoin de la protection complète du CSRF; L'utilisation de tout type de protection réduite n'est pas acceptable.
Votre configuration semble facilement attaquable par quiconque derrière le même NAT (et partage ainsi l'adresse IP), ce qui est très courant dans les maisons des gens et même de nombreux lieux de travail. Voici un exemple de scénario:
Les étapes 3 à 6 peuvent facilement se produire dans les 5 minutes.
avec uniquement Formulaire de champ caché / & A Cookie Celles-ci sont à la fois client afin que cela ne soit pas sécurisé par définition.mais corrige-moi si je me trompe, l'attaquant ne peut pas manipuler \ Voir mes données CSRF_Token, et s'il ne peut pas créer de demande de propriété intellectuelle avec ce jeton et les exercices de 5 min ..., le seul l'inconvénient est que le même jeton peut être utilisé à plusieurs reprises par le même utilisateur sur le même formulaire jusqu'à expirant ... il a l'air assez sécurisé pour moi ... La sécurité du stockage côté client est effectuée uniquement à la manière dont vous le sauvegardez, i seulement Utilisez le stockage de l'utilisateur comme unité de stockage pour mes données sécurisées cryptées qui ne peuvent pas être manipulées sans me remarquer ...
BTW, pourquoi pas seulement un nombre aléatoire? Quel est le but d'utiliser le cryptage ici?
Étant donné que les données n'ont jamais été enregistrées sur le serveur, uniquement sur le côté client, je n'aurai aucune donnée pour comparer la chaîne aléatoire à, aucun moyen de vérifier le jeton ... Si vous utilisez des sessions, le meilleur moyen est de sauvegarder une chaîne aléatoire Dans une session ... mais si vous ne souhaitez pas économiser de sessions dossiers / enregistrements de base de données pour chaque visiteur de page, ceci est mon travail autour, juste pour les formulaires de connexion / registre ...
@itai Il y a - vous comparez un jeton de la forme avec celui des biscuits.
Vous pouvez probablement utiliser un hmac ( en.wikipedia.org/wiki/hash-based_message_authentication_cod e ) au lieu d'un cryptage. Ce sera bien plus rapide.
Si vous n'utilisez qu'un serveur (par exemple: non distribué), vous ne pouvez pas enregistrer les numéros aléatoires CSRF dans une structure de données en mémoire? Vous pouvez simplement les sortir après quelques minutes.
Cela peut fonctionner avec de nombreux serveurs que vous le souhaitez (en supposant que tous partagent le même fuseau horaire), mais je commence à penser que ceci est une overkill ... String aléatoire de cookie_value à Hidden_Field_Value est bon enduh pour la connexion / le formulaire de registre .. .
Voir aussi Github.com/Deceze/kunststube-csrfp
très belle approche
@itai vous avez vrai "pense que c'est une overkilleuse ... c'est assez bon pour la connexion" - mais quand je crée un jeton rafraîchi, il n'y a pas de "champ caché"