Politik gleicher Herkunft und CORS - was ist der Sinn?

Question

Ich habe einige Probleme, die gleiche Herkunft Politik und die verschiedenen Möglichkeiten zu "umgehen" es zu verstehen.

Es ist klar, dass die Richtlinie mit demselben Ursprung als Sicherheitsmaßnahme existiert, sodass ein Skript, das von einem Server/einer Domäne stammt, keinen Zugriff auf Daten hat, die von einem anderen Server/einer anderen Domäne stammen.

Es ist auch klar, dass es manchmal nützlich ist, diese Regel zu brechen, so zum Beispiel greift eine Mashup-Anwendung auf Informationen von verschiedenen Servern zu, um die gewünschten Ergebnisse aufzubauen. Und eine der Möglichkeiten, dies zu tun, ist CORS.

1) Wenn ich nicht falsch bin, erlaubt CORS der Zielserver an den Browser zu sagen: „ist es ok für Sie Daten zu nehmen/code von mir“ durch einige Header in der Antwort hinzufügen. Wenn dies jedoch richtig ist, bedeutet dies, dass ein böswilliger Server diesen Header einfach hinzufügen könnte und der Browser den Abruf von möglicherweise schädlichen Daten oder Codes von diesem Server ermöglichen würde.

2) Auf der anderen Seite haben wir JSONP, das es uns ermöglicht, beliebigen Code oder Daten von einem Server ohne CORS zu erhalten, wodurch das Hauptziel der SOP vermieden wird. Ein bösartiger Server, der in der Lage ist, JSONP zu verwalten, kann also Daten oder Code sogar mit dem im Browser fest verdrahteten SOP einspeisen.

Also meine Fragen sind:

Ist die zweite Argumentation korrekt? Ist es die Entscheidung des Servers, ob der Browser den Inhalt akzeptieren muss? Ist die zweite Argumentation korrekt? Es ist wiederum nicht die Entscheidung des Browsers, ob er Daten akzeptiert oder nicht?

Verursacht JSONP die SOP nicht nutzlos?

Danke für die Erleuchtung mich !!

Answer 1

Wichtig ist hierbei zu beachten ist, dass, wenn der Benutzer an einem Standort http://example.com/ und die Anforderung http://example.com/delete?id=1 löscht der Benutzer einen Beitrag signiert ist, dann wird der folgende Code der Beitrag des Benutzers löschen:

<script src="http://example.com/delete?id=1" /> 

Dies wird als CSRF/XSRF-Angriff bezeichnet (Cross-Site Request Forgery). Dies ist, warum die meisten serverseitige Web-Anwendungen, die eine Transaktion Ticket verlangen: statt http://example.com/delete?id=1 Sie http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

nun folgende Angriff wird nicht funktionieren zu tun haben:

<script src="http://example.com/delete?id=1" /> 

... weil es nicht enthält den Parameter txid. Betrachten wir nun, was passiert, wenn auf die Site mit XmlHttpRequest zugegriffen werden kann. Das Skript auf dem Browser des Benutzers ausgeführt könnte hinter dem Rücken des Benutzers abrufen und analysieren http://example.com/pageThatContainsDeleteLink, die txid extrahieren und fordern dann http://example.com/delete?id=1&txid=SomethingTheUserCannotGuess

Wenn nun XmlHttpRequest nicht Sites zugreifen können einen anderen Ursprung haben, der einzige Weg, um zu versuchen, die txid abrufen würde zu versuchen, etwas zu tun:

<script src="http://example.com/pageThatContainsDeleteLink" /> 

... aber es hilft nicht, wie das Ergebnis eine HTML-Seite ist, nicht ein Stück JavaScript-Code. Es gibt also einen Grund, warum Sie <script>: s von anderen Sites einfügen können, aber nicht über XmlHttpRequest auf andere Sites zugreifen.

können Sie interessiert sein, dies bei der Lektüre: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json-vulnerability.aspx/

Dieser Angriff war gegen Google Mail wieder in den Tag und erlaubt Ihnen die Benutzer-Mails von JavaScript-Code zu holen auf einer anderen Website ausgeführt wird. Dies alles zeigt, dass das Sicherheitsmodell von WWW sehr subtil und nicht gut durchdacht ist. Es hat sich weiterentwickelt, anstatt gut gestaltet zu sein.

Wie für Ihre Frage: Sie scheinen zu denken, dass der Server http://example.com/ der bösartige ist. Das ist nicht der Fall. Unter Verwendung der Notationen meiner Antwort ist http://example.com/ der Server, der das Ziel des Angriffs ist, und http://attacker.com/ ist die Site des Angreifers. Wenn http://example.com/ die Möglichkeit eröffnet, Anforderungen mit JSONP oder CORS zu senden, ist es wahr, dass es anfällig für die CSRF/XSRF-Attacke werden kann, die ich gerade beschrieben habe. Aber es bedeutet nicht, dass andere Websites für den Angriff anfällig werden. Ähnlich, wenn http://attacker.com/ die Möglichkeit eröffnet, Anfragen mit JSONP oder CORS zu senden, wurde die Site des Angreifers gerade anfällig für einen CSRF/XSRF-Angriff. Daher kann ein falsch informierter Serveradministrator ein Loch auf seiner eigenen Website öffnen, aber die Sicherheit anderer Websites wird dadurch nicht beeinträchtigt.