In unserer Webanwendung sind wir auf die Situation gestoßen, in der wir domainübergreifende AJAX-Anrufe von einer vollständig kontrollierten Domäne zu einer anderen vollständig von uns kontrollierten Domäne durchführen müssen. Ich habe für die beste Lösung surfen und die beiden, die in den Sinn kommen, sind ein lokaler Datei-Proxy (lokale Datei mit php :: fopen) oder jquery / JSONP.
Wenn ich online nachschaue, sehe ich, dass Leute routinemäßig darüber sprechen, wie gefährlich es ist, JSONP zu benutzen, weil jemand bösartige Daten damit einbringen könnte. Das Dilemma ist, dass die meisten Argumente dagegen nicht viel Wasser zu halten scheinen, also komme ich hierher, um den Stack um Klärung zu bitten.
Was sind die spezifischen Angriffsvektoren, die durch Cross-Domain-JSONP geöffnet werden?
Nach meinem Verständnis ist der einzige Vektor für JSONP genau der gleiche Vektor, der geöffnet wird, indem er ein <script> -Tag auf Ihrer Site einfügt, dessen src sich auf jede Site befindet, die nicht von Ihnen kontrolliert wird: Sie könnten böswillig werden und User-Sessions / Cookies / Daten bearbeiten. Wenn das stimmt, dann scheint es, dass nicht das Protokoll (JSONP) das Problem ist, sondern die Quelle , aus der die Daten stammen.
Da es sich um einen Server-seitigen Proxy, ein <script> -Tag oder Ajax / JSONP handelt, besteht das Risiko, dass ich den Inhalt von jemand anderem auf meine Seite lege. Genau das macht Google Analytics mittels eines Script-Tags.
Viele Vektoren, die ich online höre, hängen von der unsachgemäßen Überprüfung der vom Benutzer übermittelten Formulare und Daten ab. In diesem Beispiel wird JSONP verwendet, um eine Datei abzurufen, die Daten in ein Formular einfügt, und dann wird das Formular zur Datenbankeinfügung gesendet. Wenn die Daten aus diesem Formular vertrauenswürdig sind, weil es sich um eine Quelle handelt, die als sicher gilt (JSONP-Daten) und ohne Validierung eingefügt wird, dann ist es wiederum nicht der JSONP, sondern die nicht ordnungsgemäß validierte Benutzereingabe. Ein Benutzer könnte die gleichen Änderungen an diesem Formular mit Firebug vornehmen, aber zuletzt habe ich überprüft, dass niemand Firebug einen Sicherheitsvektor nennt.
Das letzte Element ist die Vorstellung, dass es mit dem serverseitigen Proxy eine größere Möglichkeit gibt, die Ergebnisse zu filtern, bevor sie an den Client übergeben werden. Aber egal, ob es sich um PHP oder Javascript handelt, ich könnte die Ergebnisse filtern, um Dinge wie onclick oder iframe zu entfernen. Sicher, jemand Client-Seite könnte meine JavaScript-Funktion ändern, um die Filterung zu entfernen, aber die Filterung würde nur ihre spezifische Client-Erfahrung beeinflussen, und würde nicht für andere Benutzer geändert werden, wodurch eine permanente Multi-Client-XSS-Angriff verhindert.
Offensichtlich gibt es einige Vorteile für den serverseitigen Proxy, da dies Dinge wie die Protokollierung potentieller XSS-Angriffe erleichtern würde, aber in Bezug auf die Verhinderung des Angriffs scheinen sowohl PHP als auch Javascript adäquate Dienstprogramme zu haben. In mancher Hinsicht scheint JSONP tatsächlich sicherer zu sein als ein einfaches <script> -Tag, da das Ergebnis zumindest bei JSONP eine Funktion durchläuft, was bedeutet, dass es etwas gefiltert ist und nicht nur pauschales Vertrauen, wie es bei <script> / p>
Gibt es ein Risiko, dass ich vermisse oder übersehe? Wenn ich das Problem richtig verstanden habe, besteht kein Sicherheitsrisiko für die Verwendung von JSONP, um den Inhalt einer Datei, der wir vertrauen, von einer vertrauenswürdigen Quelle zu übernehmen. Ist das eine genaue Einschätzung?
LÖSUNG
Wenn beide Enden vertrauenswürdig sind, besteht keine Gefahr in JSONP (es ist im Grunde nur ein <script> -Tag).
Beide Skripts / JSONPs weisen die gleichen Sicherheitslücken auf, da sie automatisch ausgeführt werden und nicht einfach als Daten übertragen werden. Die Verwendung eines serverseitigen Proxys bedeutet, dass die domänenübergreifende Rückgabe als Daten übergeben und auf schädliche Inhalte gefiltert werden kann. Wenn die Cross-Domain vollständig vertrauenswürdig ist, dann ist JSONP / SCRIPT sicher, wenn es einen Risikoverdacht gibt, dann über einen Filter-Proxy weiterleiten.
Wenn Sie beide Enden der Anfrage steuern, sind die meisten der traditionellen Sicherheit -Sorgen bezüglich JSONP kein Problem.
Ein zusätzliches Problem besteht darin, dass einige Benutzer Skripts von Drittanbietern als Sicherheitsmaßnahme blockieren. Das wird auch Ihre JSONP-Anfragen blockieren. Der serverseitige Proxy-Ansatz hat dieses Problem nicht.
Es gibt einen großen Unterschied zwischen server-side-proxy und <script>/JSONP . Im ersten Fall laden Sie Daten herunter, im letzteren Fall laden Sie automatisch code
Wenn Sie einen serverseitigen Proxy erstellen, kann der JavaScript-Code XmlHttpRequest zum Herunterladen von Daten verwenden. Diese Daten werden nicht automatisch ausgeführt. Sie müssen etwas Dummes tun, wie eval() , um es auszuführen. Auch wenn das Datenformat JSON ist und der andere Server kompromittiert wurde und Ihr eigener serverseitiger Proxy die Kompromittierung nicht erfasst, haben Sie immer noch eine Verteidigungslinie, die Ihren Clientcode verfügbar macht. Sie können den JSON beispielsweise mit einem sicheren JSON-Parser und bösartiges Skript ablehnen.
Wenn Sie jedoch JSONP oder ein <script> -Tag verwenden, schließen Sie direkt den -Code einer anderen Person ein. Weil der Code (und nicht die Daten) vom Browser automatisch ausgeführt wird, ohne Ihnen die Möglichkeit zu geben, sie zu überprüfen oder zu ändern.
Zusammenfassend bietet serverseitiger Proxy Ihnen zwei zusätzliche Verteidigungslinien -