GWT RPC - T-il suffisant pour le protéger contre les CSRF?

Mise à JOUR : GWT 2.3 introduit un mécanisme plus efficace pour lutter contre les attaques XSRF. Voir http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.html

GWT du mécanisme RPC effectue les opérations suivantes sur chaque Requête HTTP

  1. Deux ensembles personnalisés en-têtes de requête - X-GWT-Permutation et X-GWT-Module de Base
  2. Définit le type de contenu text/x-gwt-rpc; charset=utf-8

La requête HTTP est toujours un POST, et sur le côté serveur méthodes GET lever une exception (méthode non pris en charge).

Aussi, si ces en-têtes ne sont pas définies ou ont la valeur faux, le serveur de traitement échoue avec une exception "peut-être CSRF?" ou quelque chose à cet effet.

Question est : Est-ce suffisant pour empêcher CSRF? Est-il un moyen de définir des en-têtes personnalisés et de changer de type de contenu dans une pure cross-site request forgery méthode?

OriginalL'auteur Sripathi Krishnan | 2010-04-09

  1. 6

    Si ce GWT RPC est utilisé par un navigateur, puis il est 100% vulnérables à CSRF. Le type de contenu peut être défini dans le code html <form> élément. X-GWT-Permutation et X-GWT-Module-Base ne sont pas sur le Flash de la liste noire de interdit les en-têtes. Ainsi, il est possible de mener une attaque CSRF à l'aide de flash. Le seul élément d'en-tête vous pouvez faire confiance pour la protection CSRF est le "referer", mais ce n'est pas toujours la meilleure approche. Utilisation de base de jetons protection CSRF chaque fois que possible.

    Voici quelques exploits que j'ai écrit qui doit faire la lumière sur l'obscur attaque que je viens de décrire. Un flash exploiter pour cela ressemblera à quelque chose comme cette et
    ici est un js/html exploiter qui change le type de contenu.

    Mon exploit a été écrit pour Flex 3.2 et les règles ont changé dans Flex 4 (Flash 10) Voici les dernières règles, la plupart des en-têtes peuvent être manipulés pour des demandes de POSTE.

    Flash script qui utilise navigateTo() pour CSRF:
    https://github.com/TheRook/CSRF-Request-Builder

    XmlHttpRequest, Flash et une foule d'autres technologies peuvent personnaliser les en-têtes de navigateur -- mais de même origine politique des coups de pied dans et permettra d'éviter un autre site de faire la demande. À moins que le serveur a un clémente crossdomain.xml ou est de retour en Access-Control-Allow-Origin arbitraire de sites web, comment la demande est-elle au travail? Qui ne nous laisse plus que avec des formes / images / iframe et autres, où même origine politique ne s'applique pas. Mais je ne sais pas d'une façon dont ils peuvent définir des en-têtes http personnalisés. Alors, comment est-il vulnérable?
    .. et oui,je suis d'accord jeton de base de la protection csrf est le meilleur moyen, mais je voudrais comprendre la faille avec leur approche.
    Très bonne question. Afin de tirer de cette exploitation, vous avez pour profiter d'un peu connu propriété de flash. J'ai posté 2 exploits faire ce que je viens de décrire, je vous encourage à les utiliser. (Si vous n'avez pas le logiciel vulnérable à tout le moins, vous pouvez voir que le POST de demande est envoyé à un autre domaine, mais le script ne peut pas "voir" une réponse en raison de la S. O. P.)
    Et non, je ne suis pas en s'appuyant sur un crossdomain.xml fichier ou le "Access-Control-Allow-Origin" en-tête.
    Merci pour les pointeurs. J'ai utilisé le code, coincé, fait quelques recherches et quelques réglages, et finalement réalisé que flash ne permettent pas de définir des en-têtes de requête http, sauf si le serveur autorise explicitement (voir mes notes ci-dessous). Mais je pourrais définir le contenu personnalisé en-tête de type via flash, et ainsi contourner les plus populaires de la version de GWT RPC. Donc dans l'ensemble, je suis d'accord avec votre réponse et de la recommandation. Merci!

    OriginalL'auteur rook

  2. 4

    GWT 2.3 introduit un mécanisme plus efficace pour lutter contre les attaques XSRF. Voir GWT RPC XSRF protection

    mise à jour de la question, donc toute personne visitant cette page peut le trouver facilement. Merci!
    n'importe quelle partie indépendante de vérifier que le courant (GWT 2.8.1) XsrfTokenServlet mise en œuvre fournit un moyen sûr de protéger contre XSRF?

    OriginalL'auteur rjrjr

  3. 3

    Je sais que j'ai posé cette question, mais après quelques jours de recherche (grâce à des pointeurs de Tour!), Je pense avoir la réponse.

    Ce que GWT fournit out-of-the-box va pas vous protéger contre les CSRF. Vous devez prendre des mesures documentées dans De sécurité pour les Applications GWT pour rester sécurisé.

    GWT RPC définit "content-type" en-tête "text/x-gwt-rpc; charset=utf-8". Alors que je n'ai pas trouver un moyen de régler cela à l'aide de formulaires HTML, il est trivial de le faire en flash.

    Les en-têtes personnalisés - X-GWT-Permutation et X-GWT-Module de Base, sont un peu plus compliqué. Ils ne peuvent pas être définies à l'aide de HTML. Aussi, ils ne peut pas être défini à l'aide de Flash à moins que votre serveur en particulier, il permet de crossdomain.xml. Voir Flash Player 10 Sécurité.

    En outre, lorsqu'un fichier SWF souhaite
    envoyer des en-têtes HTTP personnalisés n'importe où
    autre que son propre hôte d'origine,
    il doit y avoir un fichier de stratégie sur la
    Serveur HTTP à laquelle la demande est
    d'être envoyé. Cette politique de fichier doit
    énumérer le fichier SWF de l'hôte de
    origine (ou un ensemble plus large d'hôtes)
    d'être autorisé à envoyer des requêtes personnalisées
    les en-têtes d'hôte.

    Maintenant GWT du RPC est offert en deux saveurs. Il y a la vieille, personnalisé-format de sérialisation RPC, et la nouvelle, JSON à base de RPC. AFAICT, le code client définit toujours ces en-têtes de requête. Le style ancien de la RPC n'est pas maintenant appliquer ces en-têtes sur le côté serveur, et donc d'une attaque CSRF est possible. Le nouveau style de-RPC applique ces en-têtes, et ainsi, il peut ou peut ne pas être possible de les attaquer.

    Dans l'ensemble, je dirais que si vous vous souciez de la sécurité, assurez-vous d'envoyer une forte CSRF jetons dans votre demande, et ne pas compter sur GWT pour l'empêcher de vous.

    Voici les nouvelles règles pour l'établissement des en-têtes: eonflex.com/flex/4.1/langref/flash/net/URLRequestHeader.html Vous ne pouvez les mettre sur le POST, et les plus courantes sont le noir répertoriés, selon toutes les informations que vous avez posté l' "X-GWT-Permutation" élément d'en-tête peuvent être contrôlés pour les requêtes POST à l'aide de la méthode que j'ai utilisé dans mon cross-site de téléchargement de fichiers exploiter.
    Découvrez cet exemple de code qui modifie le pragma: no-cache élément d'en-tête: eonflex.com/flex/4.1/langref/flash/net/... Si vous avez eu le problème de la compilation de mon code, vous devriez essayer de compiler l'exemple.
    Votre réponse était exactement ce que je cherchais, mais il date de 2010. Je suis en train d'écrire un PoC attaque CSRF à l'encontre de l'ancien style RPC, à l'aide d'une version moderne de flash. Savez-vous si cela est encore possible? Comme la cible n'est pas crossdomain xml. Il semble que mon Flash client envoie une requête pour crossdomain xml pour le serveur, réalise il n'y a pas de tel fichier, et puis n'est-ce pas passez à la question de mon CSRF de la charge utile. Avoir de nouvelles versions de Flash essentiellement empêché ce genre d'attaque, même sur le vieux-style RPC?

    OriginalL'auteur Sripathi Krishnan

  4. 0

    Je ne suis pas sûr, si il ya un moyen facile (je serais extrêmement intéressé à trouver, aussi!), mais au moins, il semble y avoir certains moyens avancés pour atteindre arbitraire de la croix-des demandes de site avec arbitraires en-têtes: http://www.springerlink.com/content/h65wj72526715701/ je n'ai pas acheté le livre, mais le résumé et introduction ne sonnent très intéressant.

    Peut-être que quelqu'un ici à déjà lu la version complète de l'article, et peut développer un peu?

    J'ai posé pour flash code source que j'ai écrit qui modifie les en-têtes http et post pour exploiter une csrf de la vulnérabilité.
    mais s'il vous plaît re‑post.

    OriginalL'auteur Chris Lercher