JSONP : Scripts pour les requêtes de données inter-domaines

Les na­vi­ga­teurs et les ap­pli­ca­tions Web disposent de nom­breuses fonc­tion­na­li­tés et concepts pour protéger les uti­li­sa­teurs et leurs données des cy­be­rat­taques. L'un d'entre eux est la Same-Origin-Policy (SOP) que l’ancien na­vi­ga­teur Netscape a introduit en 1996 avec l'im­plé­men­ta­tion du Ja­vaS­cript. Cette charte empêche les langages de script côté client tels que Ja­vaS­cript et Ac­tionS­cript, ainsi que les langages de feuilles de style tels que CSS d'accéder aux objets (gra­phiques, vidéos, etc.) provenant d'un autre site ou URL.

Cependant, les limites fixées par la Same-Origin-Policy ne sont pas avan­ta­geuses pour tous les types de projets Web, et peuvent même dans certains cas être gênantes – notamment dans les ap­pli­ca­tions Web qui reposent sur une trans­mis­sion de données asyn­chrone entre na­vi­ga­teur et serveur (par exemple sur une base Ajax). De tels projets né­ces­si­tent des solutions pour con­tour­ner la directive, comme la méthode JSONP de JSON. C'est pré­ci­sé­ment ce que nous allons vous expliquer de manière détaillée dans les sections suivantes.

JSONP (également écrit JSON-P) est une méthode per­met­tant d’envoyer des données struc­tu­rées au format JSON entre dif­fé­rents domaines. L'acro­nyme signifie JSON (Ja­vaS­cript Object Notation) with Padding (avec formatage). Pour con­tour­ner la politique de la même origine lors de la demande de fichiers d'autres domaines, JSONP n'utilise pas l'objet « XMLHtt­pRe­quest » comme du code JSON ordinaire, mais l'élément « script » incluant un appel de fonction. Con­trai­re­ment à d'autres fichiers, les scripts peuvent être trans­fé­rés d'un domaine à l'autre sans violer la SOP.

JSONP a été inventé en 2005 par le dé­ve­lop­peur de logiciels Bob Ippolito et intégré ces dernières années dans de nombreux fra­me­works Web 2.0, tels que Dojo Toolkit, jQuery ou Google Web Toolkit en rem­pla­ce­ment du JSON ordinaire.

JSONP résout le problème de la Same-Origin-Policy en utilisant l'élément <script>. N'importe quel domaine peut être renseigné dans l'at­tri­but « src » de cet élément. Par ailleurs, la charte ne s'ap­plique pas ici. Cet attribut peut également être utilisé pour marquer les URL qui ap­par­tien­nent à un domaine étranger et pour renvoyer le code JSON et d'autres fichiers. Dans un tel cas, le script lui-même sert ex­clu­si­ve­ment de four­nis­seur de services qui transmet la requête JSONP au serveur Web respectif sans avoir d'effet spé­ci­fique. Pour que le client puisse traiter les données plus tard, le serveur les regroupe sous forme de pa­ra­mètres dans une fonction Ja­vaS­cript pré­dé­fi­nie dans le na­vi­ga­teur Web et com­mu­ni­quée au serveur dans la chaîne de requêtes de l'URL.

L'exemple suivant illustre le fonc­tion­ne­ment de JSONP :

Si ce simple script JSONP est intégré dans le code HTML d'un site Web et exécuté par n'importe quel client, les données JSON sont extraites du domaine étranger "not-origin-url.com" ("getjson"). La chaîne de requête « ?jsonp=exam­ple­Call­back » indique au serveur contacté qu’il s’agit d’une requête JSONP. En outre, il reçoit l’in­for­ma­tion selon laquelle il doit envoyer les données demandées comme paramètre de la fonction Ja­vaS­cript "exam­ple­Call­back".

Le serveur génère alors le code Ja­vaS­cript cor­res­pon­dant, y compris les in­for­ma­tions demandées en tant que paramètre - dans le cas de cet exemple, une paire nom-valeur - et le renvoie au client :

L'appel de fonction est alors exécuté par le na­vi­ga­teur comme s'il était ré­per­to­rié di­rec­te­ment dans le code HTML de la page d’origine. Cela permet au na­vi­ga­teur de traiter les données extraites de l'URL étrangère.

Une dé­mons­tra­tion plus complète de la méthode JSONP peut être consultée dans le tutoriel YouTube suivant :

JSONP est une solution con­tro­ver­sée parmi les experts pour con­tour­ner la SOP, prin­ci­pa­le­ment en raison du risque accru de sécurité associé aux requêtes de script. Ceci est dû au fait qu'un composant sup­plé­men­taire est intégré dans les processus du site Web d'origine dont le système de sécurité ne peut être influencé. Si le serveur contacté présente des vul­né­ra­bi­li­tés qui rendent possibles des in­jec­tions Ja­vaS­cript in­dé­si­rables (in­té­gra­tion de code Ja­vaS­cript) par des at­ta­quants, le serveur source est aussi au­to­ma­ti­que­ment exposé à un danger immédiat - d'autant plus que non seulement les documents JSON (comme dans l'exemple), mais aussi tous types de données peuvent être récupérés.

D'autres modèles d'attaque connus qui profitent de la méthode JSONP sont les suivants :

• RFD (Reflected File Download) : JSONP est vul­né­rable aux attaques RFD dans les­quelles les uti­li­sa­teurs clients semblent ne té­lé­char­ger que des données du domaine cible souhaité. En effet, des fichiers mal­veil­lants ou des URLs sont chargés, ce qui, dans la plupart des cas, est dû à la ma­ni­pu­la­tion des fonctions de callback.

• CSRF/XSRF (Cross-Site-Request-Forgery) : parce que l'élément <script> ignore la Same-Origin-Policy, un site Web mal­veil­lant peut demander, recevoir et in­ter­pré­ter des données d'autres ap­pli­ca­tions Web. Si l'uti­li­sa­teur est connecté au site attaqué, les at­ta­quants pour­raient utiliser ces « fausses » requêtes inter-domaines pour accéder à des données sensibles telles que les données de connexion.

  Si vous voulez utiliser des scripts JSONP dans votre propre projet Web, vous devez être ab­so­lu­ment sûr que non seulement votre propre serveur, mais aussi le serveur Web de l'ap­pli­ca­tion contactée est protégé contre de telles attaques et contre tout type de malware. Le code JSONP qui extrait des données de sources non sé­cu­ri­sées ne devrait donc pas être intégré ou autorisé.