Wie kann ich einschränken, JSON Zugriff?

Ich habe eine web-Anwendung, die zieht die Daten aus meinem neu erstellten JSON-API.

Meine statische HTML-Seiten dynamisch ruft die JSON-API über JavaScript aus der statischen HTML-Seite.

Wie beschränke ich den Zugriff auf meine JSON-API, so dass nur ich (meine Webseite) aufrufen können, es?

Falls es hilft, meine API ist so etwas wie: http://example.com/json/?var1=x&var2=y&var3=z... das generiert die entsprechenden JSON basiert auf der Abfrage.

Ich bin mit PHP zu generieren mein JSON-Ergebnis ... kann beschränken den Zugriff auf die JSON-API so einfach wie die überprüfung der $_SERVER['HTTP_REFERER'] um sicherzustellen, dass die API wird nur aufgerufen wird, von meiner domain und nicht einen remote-Benutzer?

  • Nur zur Klarstellung, Sie werden versuchen, es so nur Ihre server, können die API verwenden, oder nur Menschen, die die Anzeige von Webseiten auf Ihrem server?
  • Meine JSON-api ist unter: example.com/json?... und ich will nur meine Webseite example.com abrufen können Ergebnisse von meinem JSON-api.
  • Nur aus Neugier, warum willst du dies tun? Es ist irgendwie gegen den Strich geht, das web wäre also gut zu wissen, die Gründe, die hinter der Anforderung.
  • Anstatt einer PHP/Ruby/JSP/etc-Seite generieren, die die Ergebnisse auf meiner web-site .... die ist langsam. Ich habe einfach erstellt eine API erlaubt es mir die Abfrage der Datenbank für meine benötigten Informationen. So, jetzt, was ich Tue, ist einfach eine HTML-Seite lädt super schnell ... und dann haben die Inhalte dymanically in die Seite eingefügt, über die JSON-api. Was ich nicht zulassen möchte, dass jetzt jemand im wesentlichen dump alle Daten aus meiner Datenbank b/c habe ich jetzt erstellt diese API
  • solange Sie nicht ausgesetzt sind, Daten über Ihre API, die könnte eingestuft werden als sensible oder vertrauliche, dann würde ich mich nicht zu kümmern. Wenn Sie sind, jedoch, dann müssen Sie schauen auf SSL und validieren der client irgendwie, bevor Sie den API-Zugriff mit Benutzername/Passwort oder client-Zertifikaten.
  • So, statt der browser einen request an einen server und die Seite gebaut, auf einem high-end-server, den Sie gehen, um mehrere server-Anfragen, und verwenden Sie interpretiert javascript Kopfsteinpflaster der Seite zusammen mit dem mickrig-client. Ich hoffe, dass stellt sich heraus, um schneller für Sie. P. S. Dies ist nur teilweise tongue-in-cheek
  • Es hängt wirklich von der Skalierung und Funktionalität. Auf Skalen haben einige von uns beschäftigen sich mit der statischen HTML-serviert von einem CDN, das ist JSON-Cache als angemessen, wenn veraltete, serviert von Staatenlosen, non-sticky-Cluster, und so weiter. Bei diesen Skalen die Leistung von einem mickrigen netbook oder smartphone pro-client Zwerge von 0,1-0,01% der server core verfügbar für jede parallele Sitzung.

InformationsquelleAutor | 2009-05-13
  1. 18

    Die übliche Methode, für die Beschränkung des Zugangs zu Ihrer domain ist, stellen Sie den Inhalt mit etwas, das läuft unendlich.

    Beispiel:

    while(1);{"json": "here"} //google uses this method
for (;;);{"json": "here"} //facebook uses this method

    So, wenn Sie Holen diese per XMLHttpRequest oder ein anderes Verfahren, das ausschließlich auf Ihre domain, wissen Sie, dass Sie brauchen, um zu analysieren, aus der Endlosschleife. Aber wenn es geholt wird, über ein script-Knoten:

    <script src="http://some.server/secret_api?..."></script>

    Schlägt es fehl, weil das Skript wird nie über die erste Aussage.

    • Sagen Sie, was? Ihre Empfehlung ist die Schaffung einer unendlichen Schleife? Entweder bin ich komplett hier etwas fehlt, oder Sie ziehen an meinem Bein.
    • Außer jemand kann es immer noch aus server-side code, ohne jede Hektik und Sie einfach Streifen aus den Schlaufen.
    • Ja, JameZ, das ist richtig. Eine unendliche Schleife vorangestellt, um die JSON wird verhindern, dass deine JSON aus dem laden in Skript-Knoten. Ja, es wird nicht verhindern, dass der Zugriff von der server-zu-server. Dies ist nicht ein fix-all-Lösung. Es ist nur eine andere Ebene der Sicherheit. Es wird verhindert, dass Ihre Daten geladen werden, auf client-Seite mit dem Skript-Knoten.
    • Kann ich laden Sie es mit einem xhr, entfernen Sie den loop-Teil und fügen Sie es anschließend in eine neu erstellte Skript-block, kann ich das nicht?
    • Amarghosh: Deine Erklärung funktioniert, die aus der gleichen Domäne. Jedoch, xhr-Domäne beschränkt. Um deine Frage zu beantworten: Nein, können Sie nicht.
    • einige kehren auch unparsable code vor der json zum Beispiel angularjs erwartet eine )]}',\n am Anfang von json-Antworten.

    InformationsquelleAutor fearphage
  2. 17

    Ich glaube, Sie könnten Missverständnisse der Teil, wo die JSON-Anforderung initiiert wird vom browser des Nutzers anstelle von Ihrem eigenen server. Die statische HTML-Seite an den browser des Benutzers, dann dreht er sich um und führt den Javascript code auf der Seite. Dieser code öffnet eine neue Verbindung zurück zu Ihrem server zu erhalten, die JSON-Daten. Von Ihrem PHP-Skript Sicht der JSON-Anfrage kommt von irgendwo draußen in der Welt.

    Angesichts der oben genannten Mechanismus, gibt es nicht viel Sie tun können, um zu verhindern, dass jemand aus dem Aufruf des JSON-API-außerhalb des Kontexts der HTML-Seite.

    • Wenn das der Fall ist, wie sind die Menschen projizieren Ihre "RESTful" api ' s? Oder sind diese API alle öffentlichen?
    • In der Regel werden Sie von öffentlichen APIs. Abhängig von der website, die Sie kann oder kann nicht belegt werden, für die öffentlichkeit bestimmt sind, aber Sie alle müssen gebaut werden, mit einem Auge in Richtung Robustheit gegen bösartige (oder nur undesireable) Benutzer.
    • Also wie gehen die Menschen verhindern, dass Benutzer von der Abgabe einer REST-Abfrage, die einfach sichert alle Daten aus der web-Datenbank-Anwendungen.
    • Die API wäre in einer solchen Weise, dass es gibt keine Möglichkeit für den aufrufenden Benutzer Dinge zu tun, die Sie nicht erledigen wollen. Zum Beispiel, ein Armen-JSON-API akzeptieren würde eine SQL "where" - Klausel, und übergeben Sie diese direkt an die Datenbank. Auch wenn es desinfiziert und sicher aus-injection-Angriffe, können Sie nicht wollen, dass Ihre Benutzer Abfragen können für jeden Bereich von Datensätzen. Eine bessere API akzeptieren können eine Datensatz-ID oder Stichwörtern oder so, und zurück maximal 10 Einträge. Der Schlüssel ist, Sie nicht Vertrauen können, alles aus der Außenwelt.
    InformationsquelleAutor Greg Hewgill
  3. 5

    Meiner Meinung nach, können Sie nicht beschränken Sie den Zugriff, nur machen es schwieriger. Es ist ein bisschen wie access-restriction by obscurity. Verweis-URLs können einfach gefälscht werden, und auch mit der kurzlebigen Schlüssel kann ein Skript Holen Sie sich die Antworten ständig aktualisieren der Schlüssel.

    So, was kann wir tun?

    Identifizieren die Schwäche hier:

    http://www.example.com/json/getUserInfo.php?id=443

    Der Angreifer kann nun einfach Anfragen, alle Benutzer-info von 1 bis 1.000.000, in einer Schleife. Der schwache Punkt der auto_increment IDs ist Ihre Linearität und, dass Sie leicht zu erraten.

    Lösung: die Verwendung von nicht-numerische eindeutige IDS für Ihre Daten.

    http://www.example.com/json/getUserInfo.php?userid=XijjP4ow

    Können Sie die nicht-Schleife über diese. Stimmt, man kann noch Parsen der HTML-Seiten für die Schlüssel für alle Arten von Tasten, aber diese Art von Angriff ist anders (und leicht vermeidbaren) problem.

    Nachteil: natürlich, Sie können nicht diese Methode verwenden, um Abfragen einzuschränken, die nicht-Schlüssel abhängig ist, z.B. die Suche.

    InformationsquelleAutor stefs
  4. 4

    Jede Lösung hier Los ist, unvollkommen zu sein, wenn Sie Ihre statischen Seiten, die die API verwenden, müssen auf dem öffentlichen Internet. Da müssen Sie in der Lage sein, die client-browser schicken Sie die Anfrage und haben es geehrt werden, es ist möglicherweise, für jedermann genau zu sehen, wie Sie sind, bilden diese URL.

    Können Sie die app hinter Ihrem API-überprüfen Sie die http-referrer, aber das ist einfach zu fake, wenn jemand will.

    Wenn es nicht eine Anforderung für die Seiten statisch zu sein, könnten Sie versuchen, etwas, wo Sie ein kurzlebiges "key" generiert, der von der API und in die HTML-Antwort der ersten Seite, die Sie übergeben bekommt als parameter an die API. Dies würde hinzufügen overhead, um Ihre API-obwohl, da müsste man den server auf, die Ende erhalten Sie eine Liste der "Tasten", die gültig sind, wie lange Sie gültig sind, etc.

    So, können Sie einige Schritte, die nicht viel Kosten, aber nicht schwer zu umgehen, wenn jemand wirklich will, oder verbringen Sie mehr Zeit, um es ein kleines bisschen härter, aber es gibt keine perfekte Weg, um dies zu tun, wenn Sie Ihre API zu sein, die öffentlich zugänglich ist.

    • Dies ist wahrscheinlich der am meisten eleganten work-around, aber ich Stimme zu, es ist nur ein work-around und nicht wirklich eine Lösung (es gibt keine).
    • Was du also sagst ist, dass ... wenn ich überprüft die 'HTTP_REFERER' - zumindest bietet etwas begrenzte Sicherheit, dass nur meine website ist mit meiner JSON-api. Aber dann wieder, die 'HTTP_REFERER' können leicht gefälscht werden.
    • JamesZ korrigieren.
    • Antwort aus einer ähnlichen Frage stackoverflow.com/a/1562447/196451
    InformationsquelleAutor matt b
  5. 4

    Die kurze Antwort ist: wer kann Zugriff auf die Seiten Ihrer website wird auch in der Lage sein, um den Zugriff auf Ihre API.

    Können Sie versuchen, mit Ihrem API-erschwert durch die Verschlüsselung auf verschiedene Weise, aber da müssen Sie JavaScript-code enthalten, für die Entschlüsselung der Ausgabe der API, du bist nur sich für die Einstellung ein Wettrüsten mit jemand beschließt, Sie wollen verwenden Sie Ihren API durch andere Mittel. Auch wenn Sie in kurzlebige Schlüssel, eine bestimmt "Angreifer" könnte immer nur kratzen Sie Ihre HTML - (zusammen mit den current Key (Aktueller Schlüssel) kurz vor der Verwendung der API.

    Wenn alles, was Sie tun möchten, ist, dass andere websites von der Nutzung Ihrer API auf Ihren Webseiten, dann können Sie mit der Referrer-Header, aber im Hinterkopf behalten, dass nicht alle Browser senden, Referrer (und einige proxies strip Sie auch!). Dies bedeutet, dass Sie wollen würde, um zu erlauben, alle Anfragen fehlende Partner, und diese würden Ihnen nur teilweise Schutz. Auch, Verweis-URLs können einfach gefälscht werden, so dass, wenn einige andere Webseite wirklich will benutzen deine API-Sie können immer nur vortäuschen einen browser und Zugriff auf Ihre API von Ihren Servern.

    • Ich will nicht verschlüsseln, ich möchte einfach einschränken "die" nennen können meine JSON-api. Die einzige person, die ich will, um der Lage sein, rufen Sie die API ist meine eigene web-server und keine remote-Benutzer.
    • Ja, das ist es, was den letzten Absatz meiner Antwort zu. Sie könnten versuchen, mit dem überweiser, aber es können problemlos manipuliert werden.
    InformationsquelleAutor Laurence Gonsalves
  6. 0

    Sind Sie, oder Sie können verwenden Sie eine cookie-basierende Authentifizierung? Meine Erfahrung basiert auf ASP.NET forms-Authentifizierung, aber der gleiche Ansatz sollte zukunftsfähig sein, mit PHP mit ein wenig code.

    Die grundlegende Idee ist, wenn der Benutzer authentifiziert sich durch die web-app, ein cookie, das eine verschlüsselte Wert wird zurückgegeben, um den client-browser. Die json-api verwenden würden, die Cookies zu überprüfen, die Identität des Anrufers.

    Dieser Ansatz erfordert natürlich die Verwendung von cookies, so dass kann oder kann nicht ein problem für Sie.

    InformationsquelleAutor RQDQ
  7. 0

    Sorry, vielleicht bin ich falsch, aber... kann es mit HTTPS?

    Können Sie (?) haben Sie Ihren API-Zugriff via https://example.com/json/?var1=x&var2=y, so dass nur authentifizierte Verbraucher können Ihre Daten...

    • SSL garantiert nicht die Identität, die es einfach verhindert, dass 3rd parties sehen, die Ihre Daten während der übertragung zwischen browser und server.
    InformationsquelleAutor NilColor
  8. 0

    Sorry, es gibt kein DRM im web 🙂

    Können Sie nicht behandeln, HTML als vertrauenswürdigen client. Es ist eine nur-text-Skript interpretiert, die auf anderer Leute Computer ... wie Sie sehen, passen. Was auch immer Sie damit Ihre "eigenen" JavaScript-code erlauben Sie niemandem. Sie können nicht selbst definieren, wie lange es "Ihre" mit Greasemonkey und Firebug in der wildnis.

    Müssen Sie duplizieren alle access-control-und business-Logik zu Einschränkungen in der server-als wenn nichts davon vorhanden waren, die in Ihrem JavaScript-client.

    Den service in Ihrem SSO, Schränken Sie die URLs, die jeder Benutzer Zugriff hat, das design des service zu halten wget als client im Verstand, nicht mit Ihrem gut benommen JavaScript-code.

    • Oh, und wenn die Menschen beginnen, Ihren Dienst in einer Weise, Ihre HTML nicht erlauben? Nehmen Sie an der kostenlosen business-development-Beratung und roll with it!
    InformationsquelleAutor Szocske
Schreibe einen Kommentar