Ich habe einen JSON-Webdienst, um Heimmarker zur Anzeige auf meiner Google Map zurückzugeben.
Im Wesentlichen ruft http://example.com den Webdienst auf, um die Position aller anzuzeigenden Kartenmarkierungen wie folgt zu ermitteln:
Und es gibt eine JSON-Zeichenfolge wie:
zurück %Vor% Also nehme ich auf meiner Seite index.html diese JSON-Zeichenfolge und platziere die Kartenmarkierungen.
Was ich jedoch nicht möchte, sind Leute, die direkt zu meinem JSON-Webservice aufrufen.
Ich möchte nur, dass http://example.com/index.html meinen http://example.com/json/ -Webdienst aufrufen kann ... und nicht irgendein zufälliger Typ, der /json/ direkt aufruft.
Quesiton : Wie verhindere ich den direkten Aufruf / Zugriff auf meinen http://example.com/json/ -Webdienst?
UPDATE:
Um mehr Klarheit zu geben, http://example.com/index.html call http://example.com/json/?zipcode=12345 ... und den JSON-Service
- gibt halbempfindliche Daten zurück,
- gibt ein JSON-Array zurück,
- antwortet auf GET-Anfragen,
- Der Browser, der die Anfrage durchführt, hat JavaScript aktiviert.
Noch einmal, was ich nicht möchte, ist, dass Leute einfach meinen index.html Quellcode anschauen und dann den JSON-Dienst direkt aufrufen.
Es gibt einige gute Möglichkeiten, Clients zu authentifizieren.
Bearbeiten:
Ich habe zuerst nicht bemerkt, dass Ihr Web-Service mit clientseitigem Code aufgerufen wird. Es ist buchstäblich NICHT MÖGLICH, zu verhindern, dass Leute Ihren Web-Service direkt aufrufen, wenn Sie clientseitiges JavaScript es tun lassen. Jemand könnte einfach den Quellcode lesen.
Hier einige spezifischere Antworten, aber ich möchte den folgenden allgemeinen Punkt machen:
Alles, was über AJAX ausgeführt wird, wird vom Browser des Benutzers geladen. Du könntest ein Hacker-Leben hart machen, wenn du willst, aber letztendlich, gibt es keine Möglichkeit, mich daran zu hindern, Daten zu bekommen, die du mir bereits frei zugänglich machst . Jeder Dienst, der öffentlich verfügbar ist, ist öffentlich verfügbar, ganz einfach.
Akzeptieren Sie nur POST-Anfragen an die JSON-liefernde URL. Das hindert entschlossene Leute nicht daran, es zu erreichen, aber es wird das gelegentliche Surfen verhindern.
Wenn Sie Apache verwenden, können Sie allow / deny an Standorten setzen.
oder hier ist ein Link zu den Apache-Dokumenten in der Deny-Direktive
EDITS (reagiert auf die neuen Informationen).
Die Deny-Direktive funktioniert auch mit Umgebungsvariablen. Sie können den Zugriff basierend auf der Browser-Zeichenkette einschränken (nicht wirklich sicher, rät jedoch vom gelegentlichen Surfen ab), was immer noch XHR-Anrufe zulässt.
Ich würde vorschlagen, dass der beste Weg, dies zu erreichen, ein Token irgendeiner Art ist, das die Anfrage validiert, ist eine "gute" Anfrage. Sie können das mit einem Cookie, einem Sitzungsspeicher irgendeiner Art oder einem Parameter (oder einer Kombination) tun.
Was ich für so etwas vorschlagen würde, ist, eine eindeutige URL für den Dienst zu generieren, die nach kurzer Zeit abläuft. Mit Memcache könnte man so etwas ganz leicht machen. Diese Strategie könnte auch verwendet werden, um die Service-URL zu verschleiern (was keine tatsächliche Sicherheit bieten würde, aber die Messlatte für jemanden, der direkte Anrufe tätigen möchte, erhöhen würde).
Zu guter Letzt könnten Sie auch die Kryptoe mit dem öffentlichen Schlüssel verwenden, aber das wäre sehr schwer. Sie müssten für jede Anfrage ein neues Pub / Priv-Schlüsselpaar generieren und den Pubkey an den js-Client zurückgeben (hier ist ein Link zu einer Implementierung in Javascript) Ссылка
Sie können eine Zufallszahl als Flag hinzufügen, um zu bestimmen, ob die Anfrage von der gerade gesendeten Seite kommt:
1) Wenn index.html generiert wird, fügen Sie der JSON-Anforderungs-URL eine Zufallszahl hinzu:
Alt: http://example.com/json/?zipcode=12345
Neu: http://example.com/json/?zipcode=12345&f=234234234234234234
Fügen Sie diese Nummer dem Sitzungskontext hinzu.
2) Der Client-Browser gibt index.html aus und fordert JSON-Daten nach der neuen URL an.
3) Ihr Server erhält die json-Anfrage und überprüft die Flag-Nummer mit Session Context . Wenn abgestimmt, Antwortdaten. Andernfalls gib eine Fehlermeldung zurück.
4) Löschen Sie den Sitzungskontext am Ende der Antwort oder lösen Sie eine Zeitüberschreitung aus.
Sie müssen wahrscheinlich eine Art Cookie-basierte Authentifizierung haben. Darüber hinaus hat Ignacio einen guten Punkt bei der Verwendung von POST. Dies kann dazu beitragen, JSON-Hijacking zu verhindern, wenn in Ihrer Domain nicht vertrauenswürdige Skripts ausgeführt werden. Ich glaube jedoch nicht, dass die Verwendung von POST unbedingt notwendig ist, es sei denn, der äußerste JSON-Typ ist ein Array. In Ihrem Beispiel ist es ein Objekt.
Tags und Links javascript security json web-services