web-dev-qa-db-fra.com

Pourquoi la même politique d'origine est-elle si importante?

Je ne peux pas vraiment comprendre ce que signifie même domaine d'origine. Je sais que cela signifie que lors de l'obtention d'une ressource d'un autre domaine (par exemple un fichier JS), elle s'exécutera à partir du contexte du domaine qui la sert (comme le code Google Analytics), ce qui signifie qu'elle ne peut pas modifier les données ou lire les données sur le domaine qui "inclut la ressource".

Donc, si le domaine a.com incorpore un fichier js à partir de google.com dans sa source, que js exécutera fromgoogle.com et il ne peut pas accéder au DOM\cookies\tout autre élément sur a.com -- ai-je raison?

Voici une définition de la même politique d'origine que je ne peux pas vraiment comprendre:

La politique de même origine est un mécanisme clé mis en œuvre dans les navigateurs qui est conçu pour empêcher les contenus provenant de différentes origines d'interférer les uns avec les autres. Fondamentalement, le contenu reçu d'un site Web est autorisé à lire et à modifier d'autres contenus reçus du même site, mais n'est pas autorisé à accéder au contenu reçu d'autres sites.

Qu'est-ce que cela signifie vraiment? Pouvez-vous s'il vous plaît me donner un exemple concret?

Une autre question est: quel est le but de l'en-tête Origin et comment les demandes interdomaines existent-elles encore? Pourquoi cela n'influence-t-il pas la sécurité ou la même politique d'origine?

web-applicationweb-browserjavascriptsame-origin-policy
143
YSY

Pourquoi la même politique d'origine est-elle importante?

Supposons que vous êtes connecté à Facebook et visitez un site Web malveillant dans un autre onglet du navigateur. Sans la même politique d'origine, JavaScript sur ce site Web pourrait faire quelque chose à votre compte Facebook que vous êtes autorisé à faire. Par exemple, lisez des messages privés, publiez des mises à jour de statut, analysez l'arborescence DOM HTML après avoir entré votre mot de passe avant de soumettre le formulaire.

Mais bien sûr, Facebook veut utiliser JavaScript pour améliorer l'expérience utilisateur. Il est donc important que le navigateur puisse détecter que ce JavaScript est approuvé pour accéder aux ressources Facebook. C'est là que la même politique d'origine entre en jeu: si le JavaScript est inclus à partir d'une page HTML sur facebook.com, il peut accéder aux ressources facebook.com.

Remplacez maintenant Facebook par votre site Web de banque en ligne, et il sera évident que c'est un problème.

Quelle est l'origine?

Je ne peux pas vraiment comprendre ce que signifie le même domaine d'origine. Je sais que cela signifie que lors de l'obtention d'une ressource d'un autre domaine (par exemple un fichier JS), elle s'exécutera à partir du contexte du domaine qui la sert (comme le code Google Analytics), ce qui signifie qu'elle ne peut pas modifier les données ou lire les données. sur le domaine qui "inclut la ressource".

Ce n'est pas correct: l'origine d'un fichier JavaScript est définie par le domaine de la page HTML qui l'inclut. Donc, si vous incluez le code Google Analytics avec une balise <script>, il peut faire n'importe quoi sur votre site Web mais n'a pas les mêmes autorisations d'origine sur le site Web de Google.

Comment fonctionne la communication entre domaines?

La même politique d'origine n'est pas appliquée pour toutes les demandes. Entre autres, les balises <script> - et <img> peuvent extraire des ressources de n'importe quel domaine. Il est également possible de publier des formulaires et de créer des liens vers d'autres domaines. Les cadres et les iframes affichent les informations d'autres domaines mais l'interaction avec ce contenu est limitée.

Il existe certaines approches pour autoriser les appels XMLHttpRequest (ajax) vers d'autres domaines de manière sécurisée, mais elles ne sont pas bien prises en charge par les navigateurs courants. La manière courante d'activer la communication avec un autre domaine est JSONP :

Il est basé sur une balise <script>. Les informations, qui doivent être envoyées à un autre domaine, sont codées dans l'URL en tant que paramètres. Le JavaScript renvoyé consiste en un appel de fonction avec les informations demandées en paramètre:

<script type="text/javascript" src="http://example.com/
     ?some-variable=some-data&jsonp=parseResponse">
</script>

Le code JavaScript généré dynamiquement à partir d'exemple.com peut ressembler à:

parseResponse({"variable": "value", "variable2": "value2"})

Qu'est-ce que le Cross Site Scripting?

Cross Site Scripting est une vulnérabilité qui permet à un attaquant d'injecter du code JavaScript dans un site Web, afin qu'il provienne de l'attaquant site Web du point de vue du navigateur.

Cela peut se produire si l'entrée utilisateur n'est pas suffisamment filtrée. Par exemple, une fonction de recherche peut afficher la chaîne "Vos résultats de recherche pour [userinput]". Si [userinput] n'est pas échappé, un attaquant peut rechercher:

<script>alert(document.cookie)</script>

Le navigateur n'a aucun moyen de détecter que ce code n'a pas été fourni par le propriétaire du site Web, il l'exécutera donc. De nos jours, l'écriture de scripts intersites est un problème majeur, il y a donc du travail à faire pour éviter cette vulnérabilité. La plus notable est l'approche Politique de sécurité du conten .

122
Hendrik Brummermann

Qu'est-ce que cela signifie vraiment? Pouvez-vous s'il vous plaît me donner un exemple concret?

Exemple d'attaque 1: falsification de demande intersite (CSRF) avec un formulaire HTML

Sur la page à evil.com l'attaquant a mis:

<form method="post" action="http://bank.com/trasfer">
    <input type="hidden" name="to" value="ciro">
    <input type="hidden" name="ammount" value="100000000">
    <input type="submit" value="CLICK TO CLAIM YOUR PRIZE!!!">
</form>

Sans mesures de sécurité supplémentaires, cela:

  • la demande est envoyée. Le SOP n'interdit pas l'envoi de cette demande.
  • il comprend des cookies d'authentification de bank.com qui vous connecte

C'est le modèle de jeton de synchroniseur, seul, même sans SOP, qui empêche cela de fonctionner.

Modèle de jeton de synchroniseur

Pour chaque formulaire sur bank.com, les développeurs génèrent une séquence aléatoire unique en tant que paramètre masqué et n'acceptent la demande que si le serveur obtient le paramètre.

Par exemple, les assistants HTML de Rails ajoutent automatiquement un authenticity_token paramètre au HTML, de sorte que le formulaire légitime ressemblerait à:

<form action="http://bank.com/transfer" method="post">
  <p><input type="hidden" name="authenticity_token"
            value="j/DcoJ2VZvr7vdf8CHKsvjdlDbmiizaOb5B8DMALg6s=" ></p>
  <p><input type="hidden" name="to"      value="ciro"></p>
  <p><input type="hidden" name="ammount" value="100000000"></p>
  <p><button type="submit">Send 100000000$ to Ciro.</button></p>
</form>

comme mentionné sur: https://stackoverflow.com/questions/941594/understanding-the-Rails-authenticity-token/26895980#2689598

Donc si evil.com fait une seule demande de publication, il ne devinerait jamais ce jeton et le serveur rejetterait la transaction!

Voir aussi: modèle de jeton de synchroniseur chez OWASP .

Exemple d'attaque 2: falsification de demande intersite (CSRF) avec JavaScript AJAX

Mais alors, ce qui empêche le evil.com de faire 2 requêtes avec JavaScript, comme le ferait un navigateur légitime:

  1. XHR GET pour le jeton
  2. XHR POST contenant le bon jeton

donc evil.com essaierait quelque chose comme ça (jQuery parce que paresseux):

$.get('http://bank.com/transfer')
// Parse HTML reply and extract token.
$.post('http://bank.com/transfer', {
  to: 'ciro',
  ammount: '100000000',
  authenticity_token: extracted_token
})

C'est que le SOP entre en jeu. Bien que le $.get et $.post envoie réellement la demande authentifiée comme le formulaire HTML, le navigateur de l'expéditeur empêche le code JavaScript de lire la réponse HTML, car la demande a été envoyée à un domaine séparé!

La console développeur Chromium affiche une erreur de type:

L'accès à XMLHttpRequest à ' http://bank.com ' depuis Origin ' http://evil.com ' a été bloqué par la politique CORS: Non 'Access-Control -L'en-tête Allow-Origin est présent sur la ressource demandée.

qui a été demandé à: https://stackoverflow.com/questions/20035101/why-does-my-javascript-code-get-a-no-access-control-allow-Origin-header-is- pr

Pourquoi ne pas simplement envoyer des cookies de demande croisée à la place?

Et si les implémentations avaient une règle comme: "autoriser toute demande, mais uniquement envoyer des cookies sur le domaine actuel XHR"? Ne serait-ce pas plus simple?

Mais cela permettrait encore un autre type d'attaque: lorsque l'authentification est basée non pas sur les cookies, mais sur la source (IP) de la requête!

Par exemple, vous êtes dans l'intranet de votre entreprise et à partir de là, vous pouvez accéder à un serveur interne, qui n'est pas visible de l'extérieur et qui sert des données secrètes.

Toutes les demandes d'origine croisée sont-elles interdites?

Même en oubliant CORS, non , nous les faisons tous les jours!

De MDN :

  • Les écritures Cross-Origin sont généralement autorisées: liens, redirections et soumissions de formulaires.

    [Mon commentaire]: par exemple, lorsque vous cliquez sur un lien, vous vous attendiez souvent à vous connecter au site Web, ce qui nécessite de faire une demande GET authentifiée qui renvoie la nouvelle page.

  • L'incorporation d'origine croisée est généralement autorisée: images, CSS et Javascript externes, iframes.

  • Les lectures d'origine croisée ne sont généralement pas autorisées: XHR (exemple ci-dessus), iframe read.

    Cependant, l'accès en lecture est souvent divulgué par l'incorporation. Par exemple, vous pouvez lire la largeur et la hauteur d'une image incorporée, les actions d'un script incorporé, ou le disponibilité d'une ressource incorporée (et donc éventuellement si l'utilisateur est connecté ou non sur une donnée) domaine)

En particulier, il serait possible d'utiliser un formulaire en evil.com qui fait une demande authentifiée POST à bank.com. C'est pourquoi le SOP seul ne suffit pas: le jeton de synchronisation est également nécessaire.

Voir aussi: CSRF à OSWAP .

Autres approches de prévention

43
Ciro Santilli 冠状病毒审查六四事件法轮功

Ne t'inquiète pas. J'ai aussi trouvé difficile d'envelopper ma tête.

Il s'avère que Google Analytics peut, en théorie, faire tout ce qu'ils veulent à vos utilisateurs. (<script> tags créer une exception aux restrictions de politique d'origine)

C'est l'une des principales raisons XSS les attaques sont une mauvaise chose ™ et l'une des raisons pour lesquelles Mozilla a conçu Politique de sécurité du conten qui est maintenant - en route à être standardisé . (L'implémentation WebKit de l'attribut HTML5 iframe sandbox peut également être utile)

Parce qu'ils ne pouvaient pas échapper à la rétrocompatibilité, la politique de même origine vise davantage à empêcher des choses comme <iframe> et XMLHttpRequest à partir d'astuces comme l'utilisation de vos cookies "Remember Me" ou de dialogues de connexion mensongers pour accéder à vos comptes. (L'en-tête X-Frame-Options vous permet de verrouiller les cadres encore plus loin pour vous protéger contre des choses comme Clickjacking .)

L'en-tête Origin est utilisé par un mécanisme nommé "Partage des ressources d'origine croisée" qui permet aux sites d'accorder des exceptions limitées à la politique de même origine pour une interaction intersite sûre. (entièrement pris en charge dans tous les navigateurs actuels sauf Opera et Internet Explorer et partiellement dans IE8 + en utilisant l'objet propriétaire XDomainRequest qui omet les cookies))

Fondamentalement, lorsque vous essayez de créer un XMLHttpRequest vers un autre domaine, le navigateur fera l'une des deux choses :

  1. S'il s'agit d'une demande GET ou POST qui répond à certaines limites (que les fabricants de la norme ont déterminées à n'ajouter aucun risque supplémentaire pour CSRF attaques), le navigateur transmet simplement la demande.

  2. Sinon, il fait ce qu'on appelle une "demande de contrôle en amont", où il envoie d'abord une demande OPTIONS à la place et ne fait ce que vous avez demandé que si les vérifications réussissent pour la demande OPTIONS.

Dans les deux cas, le navigateur ajoute un en-tête Origin qui indique au site cible qui appelle. (C'est un peu comme l'en-tête Referer, mais requis et plus strictement spécifié pour assurer une sécurité appropriée)

Le serveur côté réception (celui qui dépend fortement de la même politique d'origine pour la protection) peut alors autoriser la demande en incluant un Access-Control-Allow-Origin en-tête contenant soit * ou la valeur de l'en-tête Origin de la demande.

Si ce n'est pas le cas, le navigateur rejette simplement la réponse et renvoie une erreur au rappel Javascript. MDN va dans les moindres détails (1)(2) sur ce qui se passe sous le capot dans les deux scénarios ainsi que sur les autres en-têtes que le système cible peut définir pour assouplir davantage le la sécurité de façon contrôlée. (par exemple, autoriser l'accès aux en-têtes HTTP personnalisés que vous définissez)

Les requêtes GET et le sous-ensemble autorisé de requêtes POST peuvent déjà être utilisés pour les attaques CSRF via d'autres mécanismes, à moins que l'application web cible ne soit correctement protégée, il a donc été décidé qu'il n'y avait aucun avantage à doubler la nombre de requêtes HTTP impliquées dans des services d'exploitation tels que la bibliothèque de polices Google.

19
ssokolow

En fait, dans ce cas, l'origine du script analytique Google est a.com

Citation de JavaScript: The Definitive Guide :

Il est important de comprendre que l'origine du script lui-même n'est pas pertinente pour la même politique d'origine: ce qui compte, c'est l'origine du document dans lequel le script est incorporé.

1
nandin