Jeton CSRF génération
C'est une question sur la génération de jetons CSRF.
Habituellement je voudrais générer un jeton à partir d'une pièce unique de données associées à la session de l'utilisateur, et hachée et salé, avec une clé secrète.
Ma question est en ce qui concerne la création de jetons quand il n'est PAS unique, les données de l'utilisateur à utiliser. Les séances ne sont pas disponibles, les cookies ne sont pas une option, l'adresse IP et les choses de cette nature ne sont pas fiables.
Est-il une raison pourquoi je ne peut pas inclure la chaîne de hachage dans le cadre de la demande ainsi?
Exemple de pseudo-code pour générer le jeton et l'intégrer:
var $stringToHash = random()
var $csrfToken = hash($stringToHash + $mySecretKey)
<a href="http://foo.com?csrfToken={$csrfToken}&key={$stringToHash}">click me</a>
Exemple la validation côté serveur du jeton CSRF
var $stringToHash = request.get('key')
var $isValidToken = hash($stringToHash + $mySecrtKey) == request.get('csrfToken')
La chaîne de caractères utilisé dans la table de hachage serait différent sur chaque demande. Tant qu'il a été inclus dans chaque demande, le jeton CSRF de validation pourrait se poursuivre. Depuis, il est de nouveau à chaque demande et uniquement intégré dans la page, en dehors de l'accès au jeton ne serait pas disponible. La sécurité du jeton tombe alors à l' $mySecretKey être connu que pour moi.
Est-ce une approche naïve? Ai-je raté quelque raison pourquoi cela ne peut pas fonctionner?
Grâce
- La solution proposée est vulnérable à des attaques de relecture. Le même jeton et une combinaison de touches fonctionnera indéfiniment.
Vous devez vous connecter pour publier un commentaire.
Est-il une raison pourquoi je ne peut pas inclure la chaîne de hachage dans le cadre de la demande ainsi?
CSRF les jetons sont en deux parties. Le jeton intégré dans la forme, et un jeton d'ailleurs, que ce soit dans un cookie, stockées dans une session ou ailleurs. Cette utilisation de l'ailleurs s'arrête à la page d'être autonome.
Si vous incluez la chaîne de hachage de la demande, la demande est autonome, donc, de copier le formulaire est tous un attaquant a besoin de faire, comme ils ont tous les deux pièces de la marque, et donc il n'y a pas de protection.
Même de le mettre dans l'URL du formulaire signifie qu'il est autonome, l'attaquant simplement des copies de la forme et de la soumission de l'URL.
Essayer
base64_encode(openssl_random_pseudo_bytes(16)).https://github.com/codeguy/php-the-right-way/issues/272#issuecomment-18688498 et je l'ai utilisé pour mon exemple de formulaire dans https://gist.github.com/mikaelz/5668195
Jeton CSRF pour but de prévenir l' (involontaire) de modifications des données, qui sont généralement appliqués à des requêtes POST.
Ainsi, vous devez inclure jeton CSRF pour chaque demande, les modifications de données (requête GET ou POST).
Ensuite il suffit de créer un id utilisateur unique pour chaque visiteur.
Comprennent que les id dans un cookie ou dans l'Url (si les cookies sont désactivés).
Edit:
Considérer l'événement suivant:
Vous avez connecté à votre facebook compte et ensuite entré à l'arbitraire site web.
Dans ce site il y a un formulaire que vous soumettez, qui indique à votre navigateur pour envoyer une requête POST à votre facebook compte.
Ce POSTE demande peut changer votre mot de passe ou ajouter un commentaire, etc, parce que le facebook de l'application vous reconnu comme un régime enregistré d' & utilisateur connecté. (sauf si il y a un autre mécanisme de blocage, comme CAPTCHA )
Vous avez simplement besoin de la même "symbolique" dans l'URL/la forme et dans le cookie. Cela signifie que vous pourriez avoir votre page de réglage de l'jeton de cookies à tout ce qu'elle veut (de préférence, une valeur aléatoire) par JavaScript et ensuite il suffit de passer la même valeur dans toutes les demandes qui se passe sur votre serveur (comme un URI ?param ou champ de formulaire). Pas besoin d'avoir votre serveur générant le cookie.
C'est sûr, tant que nous avons la confiance que le navigateur n'autorise pas les pages à partir d'un domaine à éditer ou lire des cookies pour d'autres domaines, et il est supposé pour être tout à fait sûre aujourd'hui.
Avoir votre serveur de générer le jeton supposer que ce jeton peuvent être transmises en toute sécurité à votre navigateur, sans être ramassé par un CSRF tentatives (pourquoi prendre le risque?). Si vous pourriez mettre plus de logique dans un serveur jeton généré, mais pour éviter CSRF il n'est pas nécessaire.
(Si je me trompe s'il vous plaît laissez-moi savoir)
Il y a des multiples de la mise en œuvre de jeton CSRF. La clé, c'est de savoir si ce jeton csrf est généré sur le côté client ou côté serveur. Parce que les modifications de mise en œuvre de façon drastique pour ces deux scénarios et de l'entropie de la marque en tant que bien.
Pour le côté serveur, SecureRandom est la manière préférée, mais dans votre cas, vous voulez générer le jeton CSRF avant qu'un utilisateur est identifié, de la fenêtre.crypto fournit cette fonctionnalité où vous pouvez générer un impossible à deviner assez chaîne à être utilisé pour le jeton CSRF.
Je pense que la meilleure idée à faire de hachage basée sur l'algorithme HMAC, c'est à dire faire de hachage chiffré par certains mot de passe de cette séquence: nom d'utilisateur+user_id+timestamp. Chaque demande de hachage doit être différent, d'horodatage doit être si vous ne voulez pas avoir une simple relecture de la table de hachage en attaque.
Je veux dire que votre approche fonctionne, parce que l'attaque CSRF est l'attaquant utilisant le navigateur de la victime à forger un statut d'utilisateur identifié, pourquoi ne peuvent-ils le faire? parce que sur la plupart de côté de serveur de la session de contrôle est basé sur un id de session dans les biscuits, et le cookie est un morceau de données sera automatiquement jointe à une requête HTTP envoyée au serveur.
Donc, il y a deux facteurs clés pour la défense de CSRF
Je recommande la lecture de CSRF de Prévention de la Feuille de Triche
CSRF utilise la session de l'utilisateur, de sorte que, si vous n'en avez pas, il n'y a pas de CSRF.