JSONP est-il sûr à utiliser?
Y a-t-il des problèmes de sécurité à prendre en compte lors de l'utilisation de JSONP?
Mise à jour : JSONP est un hack commun pour effectuer des requêtes inter-domaines. Les navigateurs modernes ont maintenant le partage de ressources Cross Origin et IE8 + ont XDomainRequest qui est similaire. Voir http://enable-cors.org/ pour plus d'informations.
JSONP est juste une inclusion de script qui vous permet d'utiliser un rappel. Vous devez cependant être conscient de falsification de requête intersite (CSRF) .
Tant que vous contrôlez le script et le serveur, JSONP n'est pas plus dangereux qu'un script inclus. Sauf si vous disposez d'un service JSONP qui renvoie des données sensibles aux utilisateurs connectés. Un site malveillant peut envoyer une demande au service (en espérant que l'utilisateur est connecté sur votre site) et récupérer les données. Le service peut vérifier le référent de la demande, mais il est possible d'usurper le référent en utilisant le flash (merci Chris Moschini).
Imaginez ce senario: - Un utilisateur se connecte à son compte bancaire sur Internet. Stockage d'un cookie de session dans le navigateur des utilisateurs. Ce site dispose d'un service jsonp avec des informations sensibles sur l'utilisateur et ses comptes. - D'autres sites ne sauront pas que l'utilisateur est connecté, mais ils pourraient faire une supposition sauvage et essayer d'accéder au service jsonp. Étant donné que l'utilisateur a un cookie de session, le navigateur recevra une réponse, et rien n'empêche le site de publier un message ajax pour enregistrer les données sensibles sur son serveur.
Mise à jour du 28 juin 2012 : Si vous voulez vous protéger contre les attaques CSRF, vous devriez lire ce billet de blog en profondeur par un expert en sécurité: http: //erlend.oftedal.no/blog/?blogid=1
Oui, vous devez être prudent, mais lorsqu'il est utilisé correctement avec des services de confiance, il est relativement sûr.
Voici un résumé des problèmes de sécurité avec JSONP, si je comprends bien:
Du point de vue du consommateur:
- Vous devez faire confiance au fournisseur pour ne pas renvoyer de code JavaScript malveillant au lieu du JSON attendu encapsulé dans le rappel JSONP que vous spécifiez.
- Il en va de même pour tous les modules complémentaires intégrés à JavaScript tiers, tels que Google Analytics.
- Elle est similaire aux attaques XSS en ce qu'elle permet à un tiers d'exécuter du JavaScript arbitraire dans votre application, cependant, vous devez d'abord choisir de faire confiance à ce tiers en faisant la demande en premier lieu.
Du point de vue du fournisseur:
- Vous ne devez pas supposer que même si les cookies des clients sont présents dans la demande que le consommateur est une page Web sous votre contrôle. Vérifiez l'en-tête Referer par rapport à une liste blanche d'URL autorisées et/ou ne comptez pas sur l'authentification basée sur les cookies.
- Analogue à une attaque CSRF/adjoint confus.
Il y a des problèmes de sécurité pour les deux parties. Le plus sérieux concerne le site incluant JSONP.
Si vous incluez un provenant d'un autre domaine (que vous ne contrôlez pas), ce domaine peut modifier le script à tout moment. Ils peuvent faire en sorte que le javascript fasse n'importe quoi dans le contexte de votre page Web, ce que votre propre javascript pourrait faire. Il n'y a aucun moyen de contourner cela si vous utilisez JSONP. Vous devriez étudier la communication interdomaines à l'aide d'iframes, ce qui est mieux fait par l'excellente bibliothèque EasyDXM.
Si vous proposez un service Web qui gère JSONP, vous devez vous protéger contre la contrefaçon de demande intersite (CSRF). C'est là que votre service Web renvoie des informations sensibles aux utilisateurs connectés. Si un utilisateur s'est connecté à votre site, tout autre site peut générer une demande GET au service JSONP, et les cookies de VOTRE domaine sont soumis avec la demande - en substance, l'authentification de l'utilisateur connecté - sauf que maintenant, la télécommande Le domaine obtient la réponse et est capable de lire les données sensibles!
La meilleure façon de se protéger contre CSRF est de générer un nonce (un nombre difficile à deviner, généré de manière aléatoire) et de le stocker dans la session. Sortez ce nonce dans tous vos formulaires sur VOS pages Web et incluez-le dans toutes les requêtes JSONP sur VOS pages. Sur le serveur, assurez-vous que le nonce est présent et correct dans la demande (que ce soit un GET, un POST, etc.) Les autres domaines ne pourront pas deviner ce nonce, et donc ne pourront pas obtenir les informations sensibles, malgré les cookies être envoyé.
Enfin, il existe un autre type de problème de sécurité: JSONP ne prend tout simplement pas en charge l'authentification des utilisateurs dans le navigateur, du type possible avec OAuth. Bien sûr, vous pouvez demander au serveur d'obtenir une sorte de jeton d'accès (comme avec OAuth) et l'utiliser. Cependant, si vous souhaitez effectuer l'authentification entièrement dans le navigateur, vous devez utiliser la communication interdomaine avec les iFrames. Je pense que c'est ainsi que OAuth 2.0 le fait. Voici comment le configurer: les pages hébergées sur votre site ont un accès complet à votre serveur. Avoir une bibliothèque javascript qui charge EasyDXM et l'utilise pour définir créer une iframe cachée sur votre site et lui parler en utilisant cela.
JSONP n'est certainement pas sûr, car il exécute simplement tout ce qui est inter-domaine en JavaScript.
solution! solution!
Créez un iframe, de préférence un bac à sable, et chargez-y JSONP. Attrapez le résultat et transmettez-le via window.postMessage
Et oui, quelqu'un a eu cette idée en premier, comme d'habitude :)
Le blog n'est plus là, mais je garde le lien ici pour crédit: http://beebole.com/blog/general/sandbox-your-cross-domain-jsonp-to-improve-mashup -sécurité /
modifier: lien vers la machine de retour
Il a utilisé le hack window.name pour la communication iframe, mais c'était pour IE6 et 7.