GWT RPC - Fait-il assez pour protéger contre CSRF?

MISE À JOUR: GWT 2.3 introduit un meilleur mécanisme pour lutter contre les attaques XSRF. Voir http://code.google.com/webtoolkit/doc/latest/DevGuideSecurityRpcXsrf.html GWT RPC - Fait-il assez pour protéger contre CSRF?

mécanisme RPC de GWT fait les choses suivantes sur chaque requête HTTP -

Définit deux têtes de requête personnalisée - X-GWT-Permutation et X-GWT-module de base
Ensembles le type de contenu en tant que text/x-gwt-rpc; charset = utf-8

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

En outre, si ces en-têtes ne sont pas définis ou ont la valeur incorrecte, le serveur échoue le traitement avec une exception "éventuellement CSRF?" Ou quelque chose à cet effet. Question: Est-ce suffisant pour prévenir CSRF? Existe-t-il un moyen de définir des en-têtes personnalisés et de modifier le type de contenu dans une méthode de contrefaçon de demande inter-site pure?

Source

2010-04-09 Sripathi Krishnan

Si ce RPC GWT est utilisé par un navigateur, il est vulnérable à 100% à CSRF. Le type de contenu peut être défini dans l'élément html <form>. X-GWT-Permutation et X-GWT-Module-Base ne figurent pas sur la liste noire de Flash banned headers. Ainsi, il est possible de mener une attaque CSRF en utilisant flash. Le seul élément d'en-tête auquel vous pouvez faire confiance pour la protection CSRF est le "referer", mais ce n'est pas toujours la meilleure approche. Utilisez une protection CSRF basée sur des jetons lorsque cela est possible.

Voici quelques exploits que j'ai écrits qui devraient faire la lumière sur l'attaque obscure que je décris. Un exploit flash pour cela ressemblera à this et here est un exploit js/html qui modifie 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 latest rules, la plupart des en-têtes peuvent être manipulés pour les requêtes POST seulement.

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

Source

2010-04-09 18:49:28 rook

XmlHttpRequest, Flash et une foule d'autres technologies peuvent définir des en-têtes de navigateur personnalisés - mais la même règle d'origine intervient et empêchera un autre site de faire la demande. À moins que le serveur ne dispose d'un fichier crossdomain.xml clément, ou renvoie Access-Control-Allow-Origin à des sites Web arbitraires, comment la requête va-t-elle fonctionner? Cela ne nous laisse que des formes/images/iframes et autres, où la politique d'origine identique 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-ce vulnérable? –

.. et oui, je suis d'accord token basé protection csrf est le meilleur moyen, mais je voudrais comprendre le défaut de leur approche. –

@sri Très bonne question. Afin de réussir cet exploit, vous devez profiter d'une propriété peu connue du flash. J'ai posté 2 exploits qui font ce que je décris, je vous encourage à les utiliser. (Si vous n'avez pas le logiciel vulnérable à tout le moins, vous pouvez voir que la demande POST est envoyée à un autre domaine, mais le script ne peut pas "voir" une réponse en raison de la SOP) – rook

Je ne sais pas s'il y a un moyen facile (je serais très intéressé à trouver cela aussi!), Mais au moins il semble pour être des moyens avancés de réaliser des requêtes inter-sites arbitraires avec des en-têtes arbitraires: http://www.springerlink.com/content/h65wj72526715701/ Je n'ai pas acheté le papier, mais le résumé et l'introduction semblent très intéressants.

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

Source

2010-04-09 20:03:19

J'ai posé le code source flash que j'ai écrit qui modifie les en-têtes http et post pour exploiter une vulnérabilité csrf. – rook

@rook: mais s'il vous plaît re-poster. – user2284570

Je sais que j'ai posé cette question, mais après environ une journée de recherche (grâce aux pointeurs de Rook!), Je pense avoir la réponse. Ce que GWT fournit dès le départ ne vous protégera pas de CSRF. Vous devez prendre des mesures documentées au Security for GWT Applications pour rester sécurisé.

GWT RPC définit l'en-tête "content-type" sur "text/x-gwt-rpc; charset = utf-8". Bien que je n'ai pas trouvé un moyen de définir cela en utilisant des formulaires HTML, il est trivial de le faire en flash.

Les en-têtes personnalisés - X-GWT-Permutation et X-GWT-Module-Base sont un peu plus compliqués. Ils ne peuvent pas être définis en HTML. En outre, ils ne peuvent pas être définies en utilisant Flash, sauf si votre serveur l'autorise spécifiquement dans crossdomain.xml. Voir Flash Player 10 Security.

En outre, lorsqu'un fichier SWF souhaite envoyer des en-têtes HTTP personnalisés partout autre que son propre hôte d'origine, il doit y avoir un fichier de stratégie sur le serveur HTTP auquel la demande est envoyée . Ce fichier de stratégie doit énumérer l'hôte du fichier SWF d'origine (ou un plus grand ensemble d'hôtes) en tant que étant autorisé à envoyer des en-têtes de demande personnalisée à cet hôte.

Maintenant RPC de GWT existe en deux saveurs. Il y a l'ancien RPC au format de sérialisation personnalisée et le nouveau RPC basé sur JSON. AFAICT, le code client définit toujours ces en-têtes de requête. L'ancien style RPC n'applique pas maintenant ces en-têtes côté serveur, et donc une attaque CSRF est possible. Le nouveau style de-RPC impose ces en-têtes, et il peut donc être possible ou non de les attaquer. Dans l'ensemble, je dirais que si vous vous souciez de la sécurité, assurez-vous d'envoyer des jetons CSRF forts dans votre demande, et ne pas compter sur GWT pour l'empêcher pour vous. GWT 2.3 introduit un meilleur mécanisme pour combattre les attaques XSRF.

Source

2010-04-10 20:30:31

@sri, Voici les nouvelles règles pour définir les en-têtes: http://www.eonflex.com/flex/4.1/langref/flash/net/URLRequestHeader.html Vous ne pouvez les définir que sur POST, et les plus communs sont noirs listé, selon toutes les informations que vous avez posté l'élément d'en-tête "X-GWT-Permutation" peut être contrôlé pour les requêtes POST en utilisant la méthode que j'ai utilisée dans mon exploit de téléchargement de fichiers intersites. – rook

Consultez cet exemple de code qui modifie l'élément d'en-tête 'pragma: no-cache': http://www.eonflex.com/flex/4.1/langref/flash/net/URLRequestHeader.html#URLRequestHeader%28%29 Si vous avez eu du mal à compiler mon code, essayez de compiler l'exemple. – rook

Votre réponse était exactement ce que je cherchais, mais elle date de 2010. J'essaye d'écrire une attaque CSRF PoC contre l'ancien RPC, en utilisant une version moderne de Flash. Savez-vous si cela est encore possible? Comme la cible n'a pas de _crossdomain, xml_. Il semble que mon client Flash envoie une requête pour _crossdomain, xml_ au serveur, se rend compte qu'il n'y a pas de tel fichier, puis ne procède pas à l'émission de la charge utile CSRF. Est-ce que les nouvelles versions de Flash ont essentiellement empêché ce genre d'attaque, même sur l'ancien RPC? – Juicy

Voir GWT RPC XSRF protection

Source

2011-09-07 18:42:40 rjrjr

a mis à jour la question afin que quiconque visite cette page puisse le trouver facilement. Merci! –

Est-ce qu'une partie indépendante a vérifié que l'implémentation XsrfTokenServlet actuelle (GWT 2.8.1) fournissait un moyen sûr de se protéger contre XSRF? – user1050755

GWT RPC - Fait-il assez pour protéger contre CSRF?

Répondre

Questions connexes