Réaliser des requêtes Javascript Cross Domain via un navigateur WEB

Réaliser des requêtes Javascript Cross Domain via un navigateur WEB

par

Une requête JavaScript Cross-Domain, également connue sous le nom de requête cross-origin, se produit lorsqu’un script JavaScript exécuté sur une page web tente de faire une requête vers un domaine différent de celui de la page web elle-même. Les navigateurs imposent des politiques de sécurité pour empêcher ces requêtes cross-domain non autorisées afin de protéger les utilisateurs contre les attaques potentielles.

Politique de même origine (Same-Origin Policy)

La politique de même origine (Same-Origin Policy) est une mesure de sécurité mise en place par les navigateurs Web pour restreindre les interactions entre les pages web provenant de domaines différents. En vertu de cette politique, une page web ne peut normalement pas effectuer des requêtes XMLHttpRequest ou Fetch vers un domaine différent de celui de la page d’origine.

Cependant, il existe des mécanismes tels que Cross-Origin Resource Sharing (CORS) qui permettent aux serveurs d’indiquer explicitement quels domaines sont autorisés à accéder à leurs ressources. Les en-têtes CORS, tels que Access-Control-Allow-Origin, sont utilisés pour déclarer les origines autorisées

Risques de sécurité des requêtes cross-domain

Nous savons tous que les requêtes cross-domain peuvent être potentiellement dangereuses sur un navigateur web en raison des risques de sécurité associés. En voici quelques raisons :

  • Violation de la politique de même origine (Same-Origin Policy) : Les navigateurs web appliquent la Same-Origin Policy par défaut, qui limite les requêtes à des ressources provenant du même domaine. Les requêtes cross-domain contournent cette politique, ce qui peut être dangereux si les mécanismes appropriés ne sont pas en place.
  • Risque d’attaque par injection de code : Les attaques Cross-Site Scripting (XSS) peuvent être facilitées par des requêtes cross-domain non sécurisées. Si un site web ne gère pas correctement les données provenant de sources externes, un attaquant pourrait injecter du code malveillant dans le site, compromettant la sécurité des utilisateurs.
  • Vol de données sensibles : Les requêtes cross-domain peuvent être exploitées pour voler des données sensibles, telles que des cookies de session. Si un site web n’est pas correctement sécurisé, un attaquant pourrait utiliser une requête cross-domain pour accéder à ces informations et usurper l’identité d’un utilisateur.
  • Attaques CSRF (Cross-Site Request Forgery) : Les requêtes cross-domain peuvent également être utilisées dans le cadre d’attaques Cross-Site Request Forgery (CSRF). C’est-à-dire qu’un attaquant force un utilisateur authentifié à effectuer une action non désirée sur un site auquel il est connecté, souvent sans que l’utilisateur en soit conscient.
  • Contournement des contrôles d’origine : Les requêtes cross-domain non sécurisés peuvent contourner les contrôles d’origine et permettre à des sites malveillants d’accéder à des ressources qui ne devraient être accessibles que depuis un domaine spécifique.

Pour atténuer ces risques, il est essentiel de mettre en œuvre des mesures de sécurité appropriées, telles que l’utilisation de la politique CORS (Cross-Origin Resource Sharing) côté serveur, la validation et la désinfection correcte des données côté client.

Utilisation de requêtes cross-domain

Les requêtes cross-domain peuvent être utilisés pour accéder à des ressources (comme des fichiers, des données ou des services) sur un domaine différent de celui où la page web actuelle est chargée. Il y a de nombreuses raisons légitimes pour lesquelles il peut être nécessaire de faire des requêtes cross-domain :

  • Intégration de services tiers : Si intégration de services tiers dans un site web, comme des API externes, il faudra exécuter des requêtes cross-domain pour récupérer des données en temps réel.
  • Partage de ressources : Parfois, il peut y avoir des ressources hébergées sur un autre domaine, telles que des images, des fichiers de polices de caractères, ou des fichiers JavaScript. Pour les charger, il faudra faire des requêtes cross-domain.
  • Authentification unique (Single Sign-On) : Dans le cas d’implémentation de mécanismes d’authentification unique qui s’étendent sur plusieurs domaines, des requêtes cross-domain peuvent être nécessaires pour vérifier l’état de connexion de l’utilisateur.
  • Communication entre applications web : Dans le cas de micro-services ou d’applications distribuées, différentes parties d’une application peuvent résider sur des domaines différents, nécessitant des requêtes cross-domain pour la communication.

Cependant, il est important de rappeler que les navigateurs appliquent la politique de même origine (Same-Origin Policy) par défaut, limitant les requêtes cross-domain pour des raisons de sécurité.

Pour autoriser de telles requêtes, le serveur distant doit inclure des en-têtes CORS (Cross-Origin Resource Sharing) appropriés dans ses réponses HTTP. Cela garantit que seules les sources autorisées peuvent accéder aux ressources.

Afin de ne pas exposer le serveur à des attaques externes, le serveur distant ne souhaitera peut-être pas inclure des en-têtes CORS appropriés dans ses réponses HTTP. Dans ce cas, cela va poser quelques difficultés pour effectuer des requêtes cross-domain.

Erreur CORS: Access-Control-Allow-Origin

Prenons comme exemple, ce code Javascript, exécuter dans un navigateur Web, permettant de récupérer au format texte le fichier robots.txt de ce site.

const url = 'https://zonetuto.fr/robots.txt';

fetch(
	url,
  {
    method: "GET",   
    headers: {
			'Accept': "text/html",
		},
  }  
).then(function(response) {
    return response.text();
}).then(function(content) {
    console.log(content);
}).catch(function(error) {
    console.log('Error: ' + error.message);
});

Lors de l’exécution, nous obtenons l’erreur suivante :

Blocage d’une requête multiorigines (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur https://zonetuto.fr/robots.txt. Raison : l’en-tête CORS « Access-Control-Allow-Origin » est manquant. Code d’état : 200.

Réf : l’en-tête CORS « Access-Control-Allow-Origin » est manquant

Le problème étant que la réponse à la requête CORS ne contient pas l’en-tête requis Access-Control-Allow-Origin, dont la fonction est de déterminer si le domaine à l’origine de la requête est autorisé à accéder à cette ressource.

Comment éviter cette erreur ? Tout en sachant que vous n’avez pas le contrôle du serveur !

Utilisation d’un proxy CORS

Donc si le problème avec la réponse du serveur est simplement le manque de l’en-tête Access-Control-Allow-Origin nécessaire, il est possible de le faire fonctionner la requête en exécutant la demande via un proxy CORS. Voici comment un proxy CORS peut être utilisé pour résoudre ce problème :

  • Configuration du serveur proxy : Un serveur proxy CORS est configuré sur le serveur côté client pour agir comme un intermédiaire entre le navigateur et le serveur distant. Ce serveur proxy est situé sur le même domaine que la page web du client.
  • Requête vers le proxy : Plutôt que de faire directement la requête vers le serveur distant, la page web effectue une requête vers le serveur proxy CORS sur le même domaine. Étant donné que la requête est du même domaine, elle ne sera pas soumise aux restrictions CORS.
  • Requête du proxy vers le serveur distant : Le serveur proxy, qui est situé sur le même domaine que la page web, peut maintenant faire une requête vers le serveur distant sans rencontrer les restrictions CORS.
  • Transmission de la réponse : Le serveur proxy reçoit la réponse du serveur distant, puis transmet cette réponse à la page web d’origine. Cette réponse inclut généralement l’en-tête Access-Control-Allow-Origin pour indiquer au navigateur qu’il est autorisé à accéder à la ressource depuis le domaine de la page web.

Problèmes de sécurité du proxy CORS

Les proxys CORS sont extrêmement utiles, mais en fonction de leur implémentation, ils peuvent présenter une faille de sécurité assez flagrante. Les proxys font une seule chose : ils acceptent une demande et servent d’intermédiaire pour envoyer cette demande ailleurs.
Un jugement de valeur doit être porté ici, quoi qu’il en soit, vous devez garder à l’esprit que l’utilisation de tout proxy comporte un risque fondamental.

Mise en œuvre

Pour cet article, nous utilisons le service CorsProxy.io qui propose un proxy gratuit, sécurisé et pratique pour résoudre les erreurs CORS.

Tout ce que vous avez à faire pour utiliser ce service est d’insérer l’URL du proxy https://corsproxy.io/ comme préfixe avant l’URL de destination, et il appellera l’URL au nom de votre application en utilisant les en-têtes CORS appropriés.

Voici le code JavaScript adapté en conséquence.

let urlproxy = 'https://corsproxy.io/?' + encodeURIComponent('https://zonetuto.fr/robots.txt');

fetch(
	urlproxy,
  {
    method: "GET",   
    headers: {
			'Accept': "text/html",
		},
  }  
).then(function(response) {
    return response.text();
}).then(function(content) {
    console.log(content);
}).catch(function(error) {
    console.log('Error: ' + error.message);
});

Conclusion

En utilisant cette approche, le serveur proxy CORS agit comme un intermédiaire qui résout les problèmes liés aux restrictions CORS, permettant ainsi à la page web et au code JavaScript d’accéder à des ressources situées sur des domaines différents.

Comme précédemment indiqué, il est essentiel de noter que la configuration du serveur proxy CORS doit être correcte pour éviter les problèmes de sécurité potentiels.

Laisser un commentaire