it-swarm-eu.dev

Wie sollten sich Web-App-Entwickler gegen JSON-Hijacking verteidigen?

Was ist die beste Verteidigung gegen JSON-Hijacking ?

Kann jemand die Standardverteidigung aufzählen und ihre Stärken und Schwächen erklären? Hier sind einige Abwehrmechanismen, die ich vorgeschlagen habe:

  1. Wenn die JSON-Antwort vertrauliche/nicht öffentliche Daten enthält, wird die Antwort nur zugestellt, wenn die Anforderung authentifiziert ist (z. B. mit Cookies, die eine authentifizierte Sitzung anzeigen).
  2. Wenn die JSON-Daten vertrauliche oder nicht öffentliche Daten enthalten, hosten Sie sie unter einer geheimen, nicht erratenen URL (z. B. einer URL mit einer Zufallszahl in 128-Bit-Kryptoqualität) und geben Sie diese geheime URL nur an Benutzer/Clients weiter, die zum Anzeigen der URL berechtigt sind Daten.
  3. Setzen Sie while(1); am Anfang der JSON-Antwort und lassen Sie den Client diese entfernen, bevor Sie den JSON analysieren.
  4. Lassen Sie den Client Anforderungen für JSON-Daten als POST (kein GET) senden und den Server GET-Anforderungen für JSON-Daten ignorieren.

Sind diese alle sicher? Gibt es Gründe, einen davon den anderen vorzuziehen? Gibt es noch andere Abwehrkräfte, die mir fehlen?

42
D.W.

Die erste Verteidigung besteht darin, an der Spezifikation festzuhalten, indem ein gültiger JSON verwendet wird, der erfordert ein Objekt als Entität der obersten Ebene . Alle bekannten Angriffe basieren auf der Tatsache, dass die Antwort gültig ist, wenn das Objekt der obersten Ebene ein Array ist Java Skriptcode, der mit einem <script> -Tag analysiert werden kann.

Wenn die JSON-Antwort vertrauliche/nicht öffentliche Daten enthält, wird die Antwort nur bereitgestellt, wenn die Anforderung authentifiziert ist (z. B. mit Cookies, die eine authentifizierte Sitzung anzeigen).

Das ist die Voraussetzung für den Angriff , keine Milderung. Wenn der Browser ein Cookie für Site A hat, wird es in alle Anfragen an Site A aufgenommen. Dies gilt auch dann, wenn die Anfrage durch ein <script> -Tag auf Site B ausgelöst wurde.

Wenn die JSON-Daten vertrauliche oder nicht öffentliche Daten enthalten, hosten Sie sie unter einer geheimen, nicht erratenen URL (z. B. einer URL mit einer Zufallszahl in 128-Bit-Kryptoqualität) und geben Sie diese geheime URL nur an Benutzer/Clients weiter, die zum Anzeigen der URL berechtigt sind Daten.

URLs gelten nicht als Sicherheitsmerkmal . Alle gängigen Suchmaschinen verfügen über Browser-Addons/Symbolleisten, die alle besuchten URLs an den Suchmaschinenanbieter zurückmelden. Während sie möglicherweise nur URLs melden, die explizit besucht werden, würde ich dies auch für JSON-URLs nicht riskieren.

Lassen Sie den Client Anforderungen für JSON-Daten als POST (kein GET) senden und den Server GET-Anforderungen für JSON-Daten ignorieren.

Dies verhindert das Einschließen von <script>.

Setze während (1); zu Beginn der JSON-Antwort, und lassen Sie den Client sie entfernen, bevor Sie den JSON analysieren.

Ich schlage eine modifizierte Version dieses Ansatzes vor: Fügen Sie am Anfang </* Hinzu . while(1) ist aus zwei Gründen problematisch: Erstens wird wahrscheinlich ein Maleware-Scanner ausgelöst (auf Clients, Proxys und Suchmaschinen). Zweitens kann es für DoS-Angriffe gegen die CPU von Web-Surfern verwendet werden. Diese Angriffe stammen offensichtlich von Ihrem Server.

28

Google verwendet " nicht analysierbare Cruft ", um sich gegen diese Art von Angriff zu verteidigen. Diese Sicherheitsanfälligkeit war in Firefox 3 behoben . Die Sicherheitsanfälligkeit ergibt sich aus der Implementierung der JSON-Spezifikation durch Browser.

3
rook

1) Wenn die JSON-Antwort vertrauliche/nicht öffentliche Daten enthält, wird die Antwort nur zugestellt, wenn die Anforderung authentifiziert ist (z. B. mit Cookies, die eine authentifizierte Sitzung anzeigen). 2) Wenn die JSON-Daten vertrauliche oder nicht öffentliche Daten enthalten, hosten Sie sie unter einer geheimen, nicht erratenen URL (z. B. einer URL mit einer Zufallszahl in 128-Bit-Kryptoqualität) und geben Sie diese geheime URL nur an Benutzer/Clients weiter, die dazu berechtigt sind siehe die Daten.

Es gibt keinen guten Grund, sowohl (1) als auch (2) zu tun.

Der erste ist ABAC und der zweite ist ZBAC. Der Versuch, durch die Verwendung mehrerer Zugriffskontrollschemata eine eingehende Verteidigung zu erreichen, macht die Dinge nur zu kompliziert.

3) Setzen Sie while(1); am Anfang der JSON-Antwort und lassen Sie den Client diese entfernen, bevor Sie den JSON analysieren.

4) Lassen Sie den Client Anforderungen für JSON-Daten als POST (kein GET) senden und den Server GET-Anforderungen für JSON-Daten ignorieren.

Dies klingt nach guten Ideen und trägt zur Tiefenverteidigung bei, da dadurch sichergestellt wird, dass Anmeldeinformationen nicht missbraucht werden können.

Zusätzlich,

5) Stellen Sie JSON nur mit vertraulichen Daten über SSL oder einen anderen sicheren Kanal bereit.

um zu verhindern, dass Daten über MITM verloren gehen.

2
Mike Samuel