it-swarm.com.de

Best Practices für JSON-Sicherheit?

Bei der Recherche zum Thema JSON vs XML bin ich auf diese Frage gestoßen. Einer der Gründe, JSON zu bevorzugen, war die einfache Konvertierung in Javascript, nämlich mit der Funktion eval(). Dies erschien mir aus sicherheitstechnischer Sicht sofort problematisch.

Daher habe ich mich eingehend mit den Sicherheitsaspekten von JSON befasst und in diesem Blogbeitrag untersucht, wie JSON ist nicht so sicher, wie die Leute glauben . Dieser Teil ragte heraus:

Update: Wenn Sie JSON 100% korrekt ausführen, befinden sich nur Objekte auf der obersten Ebene. Arrays, Strings, Numbers usw. werden alle umgebrochen. Ein JSON-Objekt kann dann eval () nicht ausführen, da der JavaScript-Interpreter den Eindruck hat, dass es sich um einen Block und nicht um ein Objekt handelt. Dies ist ein langer Weg, um sich vor diesen Angriffen zu schützen. Dennoch ist es am besten, Ihre sicheren Daten mit unvorhersehbaren URLs zu schützen.

Ok, das ist also eine gute Regel, um damit zu beginnen: JSON-Objekte auf der obersten Ebene sollten immer Objekte sein und niemals Arrays, Zahlen oder Strings. Klingt für mich nach einer guten Regel.

Gibt es noch etwas zu tun oder zu vermeiden, wenn es um JSON und AJAX bezogene Sicherheit geht?

Der letzte Teil des obigen Zitats erwähnt unvorhersehbare URLs. Hat jemand mehr Informationen dazu, besonders wie man es in PHP macht? Ich bin viel erfahrener in Java als PHP und in Java) es ist einfach (insofern kann man ein ganzes abbilden) Bereich von URLs zu einem einzelnen Servlet), während alle PHP), die ich getan habe, dem PHP= Skript eine einzelne URL zugeordnet haben.

Wie genau verwenden Sie unvorhersehbare URLs, um die Sicherheit zu erhöhen?

73
cletus

Die wichtigste Sicherheitslücke im Blog (CSRF) ist nicht JSON-spezifisch. Es ist genau so ein Loch, stattdessen XML zu verwenden. In der Tat ist es genauso schlimm, überhaupt keine asynchronen Anrufe zu haben. regelmäßige Links sind ebenso anfällig.

Wenn Leute über eindeutige URLs sprechen, meinen sie im Allgemeinen NICHT http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement . Stattdessen ist es üblicher, etwas anderes an der Anfrage eindeutig zu machen. nämlich ein Wert im FORM-Beitrag oder ein URL-Parameter.

In der Regel handelt es sich dabei um ein zufälliges Token, das auf der Serverseite in das FORMULAR eingefügt und dann bei einer Anforderung überprüft wird.

Die Array-/Objekt-Sache ist neu für mich:

Skript-Tags: Der Angreifer kann ein Skript-Tag einbetten, das auf einen Remote-Server verweist, und der Browser wertet die Antwort für Sie effektiv aus (). Die Antwort wird jedoch verworfen, und da JSON die Antwort ist, sind Sie sicher.

In diesem Fall muss Ihre Site JSON überhaupt nicht verwenden, um anfällig zu sein. Aber ja, wenn ein Angreifer zufälliges HTML in Ihre Website einfügen kann, stoßen Sie darauf.

18
Chase Seibert

Es gibt eine Reihe von Sicherheitsangriffen gegen JSON, insbesondere XSRF.

Die Sicherheitsanfälligkeit tritt auf, wenn ein Webdienst Cookies zur Authentifizierung verwendet und auf eine GET-Anforderung mit einem JSON-Array mit vertraulichen Daten antwortet.

Wenn ein Angreifer einen Benutzer, der bei einem Dienst, naive-webapp.com, angemeldet ist, zum Besuch seiner Website (oder einer Website, die einen von ihm kontrollierten IFRAME einbettet, z. B. über eingebettete Anzeigen) verleiten kann, kann er ein <script> mit einem SRC auf naive-webapp.com markieren und möglicherweise die Daten des Benutzers stehlen. Dies hängt von einer JavaScript-Eigenheit mit dem JavaScript Array -Konstruktor ab:

 <script>
   // Overload the Array constructor so we can intercept data
   var stolenArrays = [];
   var RealArray = Array;
   Array = function () {
     var arr = RealArray.apply(arguments);
     stolenArrays.Push(arr);
     return arr;
   }
 </script>
 <!-- even though the attacker can't access the cookies,
   - he can cause the browser to send them to naive-webapp.com -->
 <script src="//naive-webapp.com/..."></script>
 <script>
   // now stolenArrays contains any data from the parsed JSON
 </script>

EcmaScript 5 hat das verwirrende Verhalten behoben, das [] um Array im globalen Objekt nachzuschlagen und viele moderne Browser sind für diesen Angriff nicht mehr anfällig.

Im Übrigen ist Oil falsch in Bezug auf unvorhersehbare URLs. Kryptografisch sichere zufällige IDs in URLs sind eine gute Möglichkeit, Ressourcen zu schützen. Identitätsbasierte Sicherheit ist kein Allheilmittel, wie Oil vorschlägt. In http://waterken.sourceforge.net/ finden Sie ein Beispiel für ein sicheres verteiltes Anwendungsschema, das auf kryptografisch sicheren Kennungen in URLs basiert, für die kein Identitätskonzept erforderlich ist.

BEARBEITEN:

Wenn Sie JSON vs XML in Betracht ziehen, sollten Sie auch XML-spezifische Angriffsvektoren berücksichtigen.

XXE , XML Angriffe durch externe Entitäten, verwenden Sie handgefertigtes XML, um über die Firewall auf Dateisystem- und Netzwerkressourcen zuzugreifen.

<!DOCTYPE root 
[
<!ENTITY foo SYSTEM "file:///c:/winnt/win.ini">
]>
...
<in>&foo;</in>

Die Anwendung bettet die Eingabe (Parameter "in", der die Datei win.ini enthält) in die Antwort des Webdienstes ein.

53
Mike Samuel

es ist immer noch am besten, Ihre sicheren Daten mit unvorhersehbaren URLs zu schützen.

Betonung meiner. Was für ein Unsinn! Es ist am besten , Ihre sicheren Daten zusätzlich mit einer ordnungsgemäßen Authentifizierung und möglicherweise einer Verschlüsselung zu schützen. JSON-Austausche können weiterhin vorhandene Authentifizierungstechniken (z. B. Sitzungen über Cookies) und SSL verwenden.

Das Verlassen auf jemanden, der keine URL errät (wovon man effektiv spricht), ist nur dann eine vernünftige Technik (und auch nur dann), wenn Sie JSON zum Exportieren von Daten an einen anonymen Dritten (z. B. einen Webdienst) verwenden. . Ein Beispiel ist die verschiedene Webdienst-API von Google, bei der anonyme Benutzer über andere Websites auf Google-Daten zugreifen. Sie verwenden Domain-Referrer- und API-Schlüssel, um sicherzustellen, dass die Man-in-the-Middle-Website Gooogle-Daten bereitstellen kann.

Wenn Sie JSON nur zum Senden privater Daten an und von einem direkten, bekannten Benutzeragenten verwenden, verwenden Sie eine echte Authentifizierung und Verschlüsselung. Wenn Sie versuchen, einen Webservice bereitzustellen, kommt es wirklich darauf an, wie "sicher" diese Daten sein sollen. Wenn es sich nur um öffentliche Daten handelt und es Ihnen egal ist, wer sie lesen kann, kann ich keine Hash-URL erstellen.


Bearbeiten: Um zu demonstrieren, was sie bedeuten, betrachten Sie dies. Stellen Sie sich vor, Ihre Bank hat eine JSON-API zum Abrufen von Kontoauszügen bereitgestellt. Wenn ich nur http://yourbank.com/json-api/your-name/statement, du wärst wahrscheinlich nicht besonders erfreut.

Sie könnten jedoch eine eindeutige Zeichenfolge für Ihr Konto generieren, die in jeder JSON-Anforderung erforderlich ist, z. B .: http://yourbank.com/json-api/your-name/big-long-key-unique-to-you/statement

Ich hätte viel weniger Chancen, das zu erraten. Aber möchten Sie wirklich, dass dies der einzige Puffer zwischen Ihren wirklich sicheren Daten und potenziellen Identitätsdieben ist? Nein.

3
Oli