Forum d'entraide PHPFrance

Bonsoir tout le monde,

J'aimerai avoir votre avis sur la question à propos de ce "format" là (jsonp).

Cette technique permet de "requêter" en Ajax vers un autre domaine (Ajax cross domain). Apriori, l'Ajax cross domain n'est pas possible pour des raisons de sécurité. C'est là que le jsonp entre en jeu. Il permet de cracker la sécurité du navigateur afin d'arriver à son but. Mais voilà, le dev casse sciemment une sécurité. Il y a t'il une parade pour palier à ce problème de sécurité ? Personnellement, je ne suis pas sûr que ce soit efficace puisque la sécurité est cassée.

En cassant cette sécurité, est ce que les injections XSS et CSRF pourront être exploités ? Selon moi, je dis oui si on ne fait pas confiance au serveur distant par exemple. J'ai vu qu'il existe une autre technique qui permet de le faire un peu plus secure. Le serveur envoie un header afin de signaler l'url distante (CORS). Cependant là je mets en doute encore la sécurité.

Quelle est votre avis ?

Bonjour,

C'est là que le jsonp entre en jeu. Il permet de cracker la sécurité du navigateur afin d'arriver à son but. Mais voilà, le dev casse sciemment une sécurité. Il y a t'il une parade pour palier à ce problème de sécurité ? Personnellement, je ne suis pas sûr que ce soit efficace puisque la sécurité est cassée.

???

Absolument pas... le jsonp ne permet pas de "cracker la sécurité de navigateur" et ne pose pas de problème de sécurité plus que n'importe quel script javascript externe.

En résumé :
En ajax, on ne peut pas aller chercher des infos sur un site différent du sien, c'est ce qu'on appelle la "Same-origin policy".
Toutefois dans certains cas, il est nécessaire de charger des infos d'un site tiers, par exemple pour charger des bannières de pub issues d'une régie pub, ou même plus simplement pour charger un marqueur de statistiques afin d'avoir des stats de visites.
On peut donc intégrer une balise <script> avec un script JS qui ne vient pas du même site que le sien. Effectivement vu les possibilités du javascript (écriture/lecture de cookies, modification du DOM de la page, etc...), il ne faut pas intégrer des scripts dont on n'est pas sûr de la provenance... mais c'est ce que font tous les développeurs web depuis des années sans problème pour intégrer Google Analytics, adsense, ou les nombreuses librairies JS type jquery quand on passe par un CDN...

Le JSONP, c'est juste le fait d'utiliser une balise <script> pour charger des données d'un json d'un site tiers... C'est donc sécurisé exactement de la même manière que ce qu'on fait avec les scripts js depuis des années.

Alors bien sûr, si tu charges dans ta page un script javascript qui provient d'une site non-sûr, ton site ne sera pas sécurisé mais il est clairement exagéré de parler de faille de sécurité du navigateur ou de sécurité crackée...

J'ai vu qu'il existe une autre technique qui permet de le faire un peu plus secure. Le serveur envoie un header afin de signaler l'url distante (CORS). Cependant là je mets en doute encore la sécurité.

Ce n'est pas plus sécure, c'est exactement la même chose, ça permet d'intégrer du contenu issu d'un site tiers.

Bonsoir Arthur,

Merci pour ton avis. Quand je parle de craker la sécurité, le dev contourne/hack bien une règle de sécurité mis en place par le navigateur. Donc il casse/contourne cette sécurité. Comme tu l'as bien mentionné c'est la same origin policy. Cette sécurité est là depuis des années et je me dis que si elle n'était pas essentielle, elle ne serait plus là.

En ce qui concerne ton exemple de cdn jquery, je pense que c'est un mauvais exemple. C'est un simple lien vers la librairie sans Ajax cross domain (https://code.jquery.com/jquery-2.1.4.js). Cependant, j'ai compris ce que tu veux dire avec gg adsense.

Pour étoffer mon discours, ces liens sont très intéressants :
http://margaine.com/2014/06/28/jsonp-vs-cors.html
http://security.stackexchange.com/quest ... with-jsonp
etc.

Pourquoi on demande pas à son propre serveur (via de l'ajax ou pas) de faire une requête vers un autre serveur, de filtrer les données reçues et de les restituer au client (navigateur de madame Michu) ? Ce n'est pas plus propres et plus sécurisé ?

Je comprends bien que le serveur distant doit être de grandes confiances. Mais si ce dernier est hacké, alors il peut être lui même un attaquant. J'ai lu aussi, qu'il fallait protéger en plus des attaques CSRF pour ce type de script.

Merci pour ton avis. Quand je parle de craker la sécurité, le dev contourne/hack bien une règle de sécurité mis en place par le navigateur. Donc il casse/contourne cette sécurité. Comme tu l'as bien mentionné c'est la same origin policy. Cette sécurité est là depuis des années et je me dis que si elle n'était pas essentielle, elle ne serait plus là.

Le JSONP existe depuis 10 ans, si il présentait un risque grave de sécurité, ça fait longtemps qu'il aurait disparu.

En ce qui concerne ton exemple de cdn jquery, je pense que c'est un mauvais exemple. C'est un simple lien vers la librairie sans Ajax cross domain (https://code.jquery.com/jquery-2.1.4.js).

Ce n'est pas un simple lien, c'est un fichier javascript qui est exécuté dans ta page donc on peut mettre de l'ajax ou ce qu'on veut dedans..
Si le domaine code.jquery.com se fait pirater, tous ceux qui ont intégré cette librairie pourrait avoir des problèmes sur leur site.

Pourquoi on demande pas à son propre serveur (via de l'ajax ou pas) de faire une requête vers un autre serveur, de filtrer les données reçues et de les restituer au client (navigateur de madame Michu) ? Ce n'est pas plus propres et plus sécurisé ?

Plus propre non, plus sécurisé oui car on rajoute un intermédiaire qui filtre.