Quels sont les risques de sécurité liés à l'activation des cors sur localhost?
J'ai une application mobile basée sur Cordova qui utilise une API via un serveur local sur mobile. L'application mobile définit Origin comme Localhost. Ici, cors entre en jeu et je ne peux pas faire la demande. Désormais, ces API peuvent être utilisées via un terminal, un facteur et d'autres environnements sans navigateur sans déclencher CORS.
Maintenant, dans ce scénario, quels sont les risques d'activer les cors sur localhost? Juste pour clarifier, je veux mettre la liste blanche des cors pour l'hôte local en production.
La réponse dépend vraiment de l'API que vous avez créée et de son fonctionnement. Ce site donne une très bonne explication sur les biens et les inconvénients de CORS. En bref, l'auteur crée une API fictive qui est utilisée pour envoyer des e-mails à partir d'un autre domaine. Il déclare:
Si vous utilisez une authentification basée sur des cookies de session, vous ne devriez probablement pas autoriser les demandes CORS de tout le monde. Un site Web malveillant peut envoyer des demandes d'envoi d'e-mails à api.yoursebsite.com via une demande AJAX sans l'autorisation spécifique de votre utilisateur.
C'est (dans son cas hypothétique) la réponse à la question "quels sont les risques de permettre aux cors"? Dans ce cas, il donne également plus d'informations sur la façon de penser l'atténuation:
Si l'utilisateur a des cookies de session valides dans son navigateur, ils seront utilisés pour s'authentifier sur api.yoursebsite.com et cela entraînerait l'envoi d'e-mails indésirables. Dans la plupart des cas, les demandes dangereuses seront "contrôlées en amont", ce qui signifie que le domaine doit être approuvé avant même de pouvoir envoyer une demande. Cela empêchera toute activité malveillante de se produire.
Cela indique (de manière légèrement cachée) ce que dandavis a déjà dit: CORS n'a pas grand-chose à voir avec la sécurité. La sécurité se fait côté serveur. Le SOP ne sera pas obéi par les pirates de toute façon.
Dans votre cas, d'après ce que je comprends, vous souhaitez activer localhost en tant que domaine via CORS afin que les demandes puissent être effectuées via un domaine différent? Si c'est correct je pense que vous ne rencontrerez aucun problème de sécurité réel . À la condition que vous ouvriez une socket liée uniquement à l'adresse de bouclage (localhost), la seule façon pour quelqu'un d'accéder à cela (de manière malveillante ou d'une autre manière) serait: Il a déjà accès à l'adresse de bouclage. Cela signifie: il a déjà accédé à l'appareil.
Basé sur le commentaire très juste de Conor Mancone: CORS protège principalement contre les demandes de lecture non autorisées. Il ne protège pas le serveur contre les écritures ou ne déclenche pas d'actions non autorisées. Cela doit être appliqué par un concept d'autorisation.
Non, ce n'est [~ # ~] pas [~ # ~] (nécessairement) sûr. Les autres réponses sont généralement correctes, sauf qu'elles font deux hypothèses (courantes, mais incorrectes): que localhost est toujours 127.0.0.1, et qu'un serveur Web fonctionnant sur votre machine est celui que vous vouliez exécuter. CE NE SONT PAS DES HYPOTHÈSES SÉCURITAIRES.
Certaines machines, en raison d'une modification délibérée dans un but ou simplement parce que le fichier HOSTS est minimal (ou manquant), ne définissent pas localhost comme 127.0.0.1 (ou :: 1 pour IPv6) et effectuent donc une recherche DNS pour ce nom. Le DNS n'est bien sûr généralement pas sécurisé; un attaquant sur le même réseau (ou n'importe où entre vous et un serveur DNS désireux de déclarer avec autorité à quelle adresse IP "localhost" est mappé) peut injecter une réponse DNS en spécifiant sa propre adresse IP. Votre application charge ensuite le contenu Web à partir du serveur Web de l'attaquant. L'attaquant peut envoyer à la victime du contenu Web malveillant qui vole les informations d'identification à votre service, vole le contenu de votre compte, abuse malicieusement de votre compte, utilise des ponts API JS vers natif pour attaquer votre appareil (ou au moins accéder de manière malveillante aux données du mobile l'application peut voir), etc.
OK, et si vous utilisiez "127.0.0.1" au lieu de "localhost"? Les adresses IP n'ont jamais besoin de passer par DNS, 127.0.0.1 est toujours routé uniquement vers votre propre machine, et ça devrait aller, non?
Encore une mauvaise idée! TCP ne respectent pas l'isolement des privilèges entre les utilisateurs (ou entre les applications en bac à sable). Si votre utilisateur mobile possède une application sommaire qui exécute un serveur Web sur ce port, votre application se connectera au serveur malveillant au lieu de celui que votre application a essayé de lancer (qui n'aura pas réussi à lier le socket, car il est déjà utilisé). Vous pouvez presque certainement le faire également dans l'App Store; il n'utilise pas d'API non autorisées ou quoi que ce soit, juste servir du contenu Web sur un socket de bouclage lié à un port particulier (le même que vous). De même sur les serveurs/ordinateurs de bureau/ordinateurs portables, si votre machine permet aux non-administrateurs de se connecter à distance (via SSH, bureau à distance, etc.), alors l'un des ces utilisateurs peuvent faire tourner un serveur Web malveillant sur le port que vous utilisez et attendre que votre application s'y connecte.
Bien sûr, même sans aucune tentative malveillante, toute cette idée est juste fragile . Comme je l'ai mentionné ci-dessus, il n'y a aucune garantie qu'aucun autre processus n'exécute un serveur Web sur le même port que vous avez choisi. Il n'y a que 2 ^ 16 d'entre eux à choisir, et pour certaines plages, le système d'exploitation lui-même peut lier de manière aléatoire les connexions sortantes à ce port afin qu'il puisse être utilisé par une application client (comme un navigateur Web) plutôt que par un serveur. Quoi qu'il en soit, le serveur utilisé pour offrir votre contenu Web ne parviendra pas à lier le port, votre application ne pourra pas parler au serveur auquel elle s'attend et votre utilisateur aura une mauvaise expérience.
Notez que cela n'a rien à voir avec CORS. [~ # ~] quelle que soit [~ # ~] l'origine à partir de laquelle vous chargez le contenu, votre serveur devra autoriser cette origine à voir les réponses Web.
Le point important est de s'assurer que le contenu Web est chargé en toute sécurité et HTTP par rapport à la normale TCP - c'est-à-dire, sans TLS ou d'autres moyens d'authentifier et de protéger la connexion - n'est pas sécurisé!
Solution: chargez simplement le contenu (via HTTPS) à partir de vos serveurs Web accessibles sur Internet. Ensuite, votre application n'a pas besoin de charger quoi que ce soit sur HTTP, votre service Web n'a pas besoin d'autoriser les demandes d'une page Web chargée via HTTP, et l'application peut être sûre qu'elle charge le contenu du bon serveur.
Vous pouvez même diffuser le contenu du même domaine, de sorte que les demandes cross-Origin (c'est-à-dire CORS) ne soient même pas nécessaires! Utilisez simplement les anciennes requêtes XMLHttpRequests (ou Fetch, sans CORS) et extrayez tout ce qui est lié à CORS à partir du service Web.
L'heure du conte:
L'ancienne entreprise pour laquelle je travaillais avait un produit qui faisait quelque chose comme ce que vous décrivez - charger des données d'un serveur Web local dans une vue Web - et nous avons rencontré un problème vraiment drôle où certaines personnes signalaient que la vue Web était juste. .. vide. Pas de contenu. Le serveur local était en cours d'exécution, le contenu était empaqueté et installé correctement, la vue Web essayait de faire les demandes Web ... mais il semblait que le serveur ne répondait pas. Pour faire court, nous l'avons finalement retrouvé jusqu'à ce que "localhost" ne soit pas défini sur ces machines. Ce n'était que quelques utilisateurs sur environ 10 000 (sur Mac, car c'était la seule plate-forme qui exécutait notre application), mais c'était assez un problème que nous avons cessé d'utiliser "localhost". Bien sûr, "127.0.0.1" s'est avéré ne pas être sécurisé non plus, comme je l'explique ci-dessus, mais cette décision a été prise avant qu'il n'y ait un responsable de la sécurité dans l'équipe.