Pourquoi ne HttpAntiForgeryException se produire de façon aléatoire, même avec un statique de la Machine à Clé?

Nous avons une ASP.NET MVC 2 (.NET 4) de l'application en cours d'exécution sur Windows Azure (plus tard 2.x version de l'OS) avec deux instances de rôle web.

Nous d'utiliser l'anti-faux jeton fourni par MVC pour toutes les requêtes POST, et nous avons établi une statique de la Machine Clé dans le web.config, donc tout ce qui fonctionne sur plusieurs ordinateurs et entre les redémarrages. 99,9% des cas, il fonctionne parfaitement.

Chaque maintenant et puis, cependant, nous enregistrons une HttpAntiForgeryException, avec le message "Une nécessaire anti-faux jeton n'a pas été fourni ou n'est pas valide."

Je sais que le problème pourrait être les cookies ne sont pas autorisés dans le navigateur, mais nous les avons vérifiées et que les cookies sont activés et d'être envoyé en arrière et en avant correctement.

L'erreur se produit avec une variété de navigateurs et, évidemment, provoque des problèmes pour les utilisateurs, car ils ont pour répéter l'opération ou ils peuvent perdre des données. Qu'il suffise de dire, nous n'avons pas été en mesure de reproduire le problème sur place, mais il ne se produit que sur Windows Azure.

Pourquoi cela se produit-il? Comment peut-on l'éviter?

J'ai vérifié avec le gars sécurité (sur le MVC de l'équipe) et Darin est probablement droit - le nom d'utilisateur, probablement changé.

OriginalL'auteur Dario Solera | 2012-03-29

  1. 17

    Je suis tombé sur cette très récemment et a trouvé deux causes.

    1. Navigateur restaure la dernière session ouverte pour la page mise en cache

    Si vous avez une page qui est cachable " qui effectue un post à votre serveur (c'est à dire antiforgery sera sur) et que l'utilisateur a leur navigateur configuré pour restaurer la dernière session au démarrage (cette option existe dans chrome) la page sera affichée à partir du cache. Toutefois, la demande de vérification cookie ne sera pas là parce que c'est un navigateur un cookie de session et est supprimée lorsque le navigateur est fermé. Depuis le cookie est allé vous obtenez la lutte anti-contrefaçon exception. Solution: Retournez en-têtes de réponse, de sorte que la page n'est pas mis en cache (c'est à dire Cache-Control:private, no-store).

    2. Condition de course si l'ouverture de plus d'un onglet sur le lancement de votre site

    Les navigateurs ont la possibilité d'ouvrir un ensemble d'onglets au démarrage. Si plus d'un de ces frappez votre site qui renvoie à une demande de vérification de cookie, vous pouvez frapper une situation de concurrence où la demande de vérification cookie est écrasé. Cela se produit parce que plus d'une demande est placé sur votre serveur à partir d'un utilisateur qui ne dispose pas de la demande de vérification de cookie ensemble. La première demande est traitée et définit la demande de vérification de cookie. Suivant la deuxième demande est traitée, mais il n'a pas envoyé le cookie (n'avait pas été encore fixé au moment de la demande) afin que le serveur génère un nouveau. Le nouveau remplace le premier, et maintenant que la page obtiendrez un antiforgery demande d'exception lors de la prochaine effectue un post. Le framework MVC ne gère pas ce scénario. Ce bug a été signalé à la MVC de l'équipe de Microsoft.

    Je vais voir à la condition 2. Il ne se produit que pour le premier utilisateur. Une fois la page chargée pour le premier utilisateur, il ne se produit plus.

    OriginalL'auteur Ed Hintz

  2. 7

    L'anti faux jeton contient le nom de l'utilisateur actuellement connecté l'utilisateur lorsqu'il est émis. Et lors de la vérification de sa validité, qui est actuellement connecté l'utilisateur est vérifiée par rapport à celle qui est utilisée lorsque le jeton a été émise. Ainsi par exemple, si vous disposez d'un formulaire dans lequel l'utilisateur n'est pas encore authentifié et vous émettez un anti faux jeton, il n'y aura pas le nom d'utilisateur stockés dans. Si lorsque vous soumettez le formulaire vous authentifier l'utilisateur, alors le jeton ne sera plus valide. De même pour les journaux.

    Voici comment le fait de Valider la méthode ressemble à ceci:

    public void Validate(HttpContextBase context, string salt)
{
    string antiForgeryTokenName = AntiForgeryData.GetAntiForgeryTokenName(null);
    string str2 = AntiForgeryData.GetAntiForgeryTokenName(context.Request.ApplicationPath);
    HttpCookie cookie = context.Request.Cookies[str2];
    if ((cookie == null) || string.IsNullOrEmpty(cookie.Value))
    {
        throw CreateValidationException();
    }
    AntiForgeryData data = this.Serializer.Deserialize(cookie.Value);
    string str3 = context.Request.Form[antiForgeryTokenName];
    if (string.IsNullOrEmpty(str3))
    {
        throw CreateValidationException();
    }
    AntiForgeryData data2 = this.Serializer.Deserialize(str3);
    if (!string.Equals(data.Value, data2.Value, StringComparison.Ordinal))
    {
        throw CreateValidationException();
    }
    string username = AntiForgeryData.GetUsername(context.User);
    if (!string.Equals(data2.Username, username, StringComparison.OrdinalIgnoreCase))
    {
        throw CreateValidationException();
    }
    if (!string.Equals(salt ?? string.Empty, data2.Salt, StringComparison.Ordinal))
    {
        throw CreateValidationException();
    }
}

    Une façon possible de déboguer c'est de recompiler ASP.NET MVC, à partir de son code source, journal exactement quels sont les cas que vous entrez lorsque l'exception est levée.

    La sécurité gars sur le ASP.NET MVC équipe d'accord, le nom d'utilisateur, probablement changé. Maintenant que MVC est open source, vous pouvez construire un diagnoistic branche. Une petite remarque, L'AF jeton ne PAS contenir le nom d'utilisateur - le code affiche le nom d'utilisateur vient de la forme de jeton, pas le cookie jeton.
    Le problème est que nous n'utilisons pas ASP.NET l'authentification et nous n'avons jamais mis le nom d'utilisateur/identité. Pouvez le changement de nom d'utilisateur sur son propre (à condition que l'application s'exécute en tant que Service Réseau sur Azure)?
    Avez-vous essayé de recompiler ASP.NET MVC, à partir du code source et de traçabilité de cas dans lequel le antiforgery d'échec de la vérification?

    OriginalL'auteur Darin Dimitrov

  3. 1

    J'ai un peu de MVC3 web apps qui se présente assez régulièrement aussi. La majorité d'entre eux sont parce que le client n'est pas d'envoyer un POST corps. Et la plupart de ces sont IE8 en raison de certains bug avec des requêtes ajax précédant une forme régulière post. Il existe un correctif pour IE qui semble traiter les symptômes, qui prouve que c'est un client bug dans ces cas

    http://support.microsoft.com/?kbid=831167

    Il y a quelques discussions sur la question à travers le web, rien de bien utiles cependant, je suis absolument pas sur de jouer avec keep-alive délais d'attente qui est une "solution" à certains endroits...

    https://www.google.com/search?q=ie8+vide+post+corps

    Je n'ai jamais été capable de le reproduire avec une variété de tentatives pour réinitialiser les connexions entre les POTEAUX alors je crains que je n'ai pas de véritable solution pour le cas de l'IE vide POST corps. La façon dont nous avons atténué un peu est de faire en sorte que nous n'avons jamais utiliser la méthode POST quand juste de la récupération des données via ajax.

    Si vous vous connectez la demande complète, vérifier pour voir si le corps POST est vide, et si elle est, il va probablement être un vieux IE. Et je ne veux pas Content-Length: 0, il ont généralement un Contenu de Longueur qui semble correcte dans les en-têtes, mais il y aura littéralement rien, après les en-têtes de la requête.

    L'ensemble de la problématique est encore un mystère pour moi, mais parce que nous obtenons toujours sauf exception où il y a un POSTE complet du corps. Nos noms d'utilisateurs ne changent jamais et nos clés sont statiques ainsi, je n'ai pas essayé d'ajouter de débogage à la source, si jamais je s'en que je vais faire part de mes constatations.

    OriginalL'auteur JeremyWeir

  4. 0

    Il ya un couple d'options pour ce que vous pourriez essayer. Vous pouvez essayer de l'accès distant à la machine et en regardant le journal des événements pour voir si vous pouvez obtenir plus d'informations à partir de qu'en ce qui concerne où ce qui se passe. Si cela ne fonctionne pas, vous pouvez utiliser DebugDiag ou un autre outil pour capturer un cliché du processus (DebugDiag vous permettra de capturer à la fois de cette exception spécifique). Et puis regarder pour voir ce qui se passe.

    Si vous n'arrivez pas à le comprendre, à partir de là, vous pouvez toujours créer un dossier de prise en charge avec Microsoft pour vous aider à étudier.

    OriginalL'auteur Tom