J'ai un site qui montrera des informations sensibles. J'utilise Anti Forgery Tokens etc pour protéger contre XSRF dans POSTS. Cependant, je suis inquiet à l'idée que quelqu'un puisse voir les informations sensibles d'un GET. Quelle est la pratique recommandée pour protéger les données en lecture seule envoyées via un GET dans .Net MVC 2?Protection XSRF GET .net mvc
Si vous êtes sûr que les requêtes GET sont en lecture seule, vous n'avez rien à craindre de XSRF. Il n'est pas possible de voler des informations d'un autre site web en utilisant juste XSRF, et donc vous n'avez pas besoin de protéger les URL via un jeton. En fait, l'utilisation de jetons dans l'URL rendra impossible l'utilisation de signets.
Cela dit, vous devriez être sûr à 100% qu'il n'y a pas de vulnérabilités XSS dans votre application. S'il y en a, un attaquant n'a pas besoin de s'embêter avec XSRF et des jetons imprévisibles.
La protection XSRF sur les données POST (utilisant des jetons comme vous l'avez dit) devrait également fonctionner sur les données GET. Du point de vue d'un pirate, une falsification GET est beaucoup plus facile que la falsification POST (à la première publication d'un lien, à la seconde vous devez pointer vers un site Web malveillant avec des formes iframe cachées et autosubmit), mais les deux échouent si les jetons sont vérifiés.
Exemple: affichant un lien comme celui-ci:
www.domain.tld/page.aspx get = données & jeton = token_given_to_hacker de
ne devrait pas retourner quoi que ce soit, ou tout simplement une erreur? pour ceux qui ont d'autres jetons. De cette façon, aucune action sensible n'est faite pour les mauvaises personnes. Ceci est xsrf, avec ceci vous ne pouvez pas voler d'information, mais obligez les autres à soumettre des formulaires et à prendre des mesures qui résultent seulement des pirates. Par exemple: Modification d'un e-mail, sur un formulaire e-mail, dans l'e-mail du pirate. Supposons que vous ayez un formulaire GET, avec 1 champ: le nouvel email (par souci de simplicité). Lorsque soumis l'URL ressemble à ceci:
www.domain.tld/[email protected]
Maintenant, si un message de hacker un lien sur votre forum avec l'URL:
www.domain.tld/[email protected]
Tous ceux qui clique dessus, recevra un nouvel e-mail, des pirates. Mais si vous y mettez un jeton, et que vous le vérifiiez à chaque fois, l'action ne sera effectuée que pour ceux qui ont le même jeton à la demande de la page, dans ce cas le lien ne fonctionnera que pour l'utilisateur qui l'a posté, et personne d'autre.
Vous pouvez également protéger les formulaires sensibles, comme la modification d'un e-mail, d'un mot de passe, etc. avec un champ de mot de passe. Notez que ce captcha n'est pas vraiment utile ici.
le formulaire sensible soumet doit être impossible à mettre en signet – SinistraD
S'il s'agit d'un formulaire qui modifie les données, il doit alors s'agir d'un POST, suivi d'une redirection vers une URL GET. Si son formulaire submit qui agit uniquement comme une sorte de filtre, il peut toujours être un GET, et il n'y a aucune raison de sacrifier les URL bookmarkable. –
Je suis inquiet pour le scénario suivant. Un autre site est vunerable à XSS (ou est un site malveillant accessible via l'ingénierie sociale).Un utilisateur est connecté à mon site et va sur le site malveillant, cela fait une demande GET Javascript à par exemple comptes/Index et a maintenant une copie de la liste des comptes qu'il peut publier de façon invisible sur un autre serveur web. –