Je veux trouver une solution de plate-forme / langue agnostique pour vous assurer que l'origine d'un poste de formulaire provient d'une source attendue. C'est à dire. Page1.aspx Postage sur pages2.php dans le même site Web.
Spécifiquement ce que j'essaie de faire ici, c'est empêcher la demande de demande de demande.
3 Réponses :
Utilisez un champ masqué de votre formulaire, qui contient un jeton votre application générée. Stockez le jeton dans la session d'utilisateur. Lorsque le formulaire est soumis, votre application vérifiera que la valeur du champ masqué est identique à la valeur stockée dans la session utilisateur.
Si c'est identique, vous savez que le formulaire soumis vient d'où il devrait venir.
Mais mettre une limite de temps sur la validité de ce jeton, pour empêcher sa copie et réutilisée indéfiniment.
Vous pouvez inclure dans la forme d'un champ caché qui serait le SHA1HASH ("SECRET-SECRET" + REMOTE_IP + PERSESSIRECRET).
Le PersessseCret est quelque chose que vous avez autogène au début de la session. "Certains-secrets" est une valeur secrète globale - qui aidera un peu un peu au cas où la persévération générée au hasard est de ne pas être suffisamment aléatoire.
Ensuite, faites le même calcul sur la soumission de formulaire et vous savez qu'il est probablement soumis auprès du même client que celui-ci a été envoyé. (Bien sûr, si vous avez plusieurs clients derrière l'adresse unique, comme un proxy ou un NAT, vous ne pouvez pas la distinguer de manière fiable).
Vieux fil, mais pourrait toujours être utile.
Si vous n'avez pas de jeu d'informations de session (meilleure option), vous pouvez inclure un champ masqué avec un horodatage crypté, puis la comparer (après la dé-crypte) à l'heure actuelle du processus pour vous assurer qu'il est relativement proche de la fin. et donc aussi récent que vous le juge nécessaires.
Cela n'empêche pas nécessairement le CSRF (Falsification de la demande croisée) mais protège plutôt contre les attaques de relecture, une chose différente.
ASP.NET a des cours d'assistance à faire cela et d'empêcher les attaques / demandes de domaines autres que les vôtres. blog.stevensanderson.com/2008/09/01/...