it-swarm.com.de

Sichern einer API für den mobilen Zugriff

Ich habe eine schöne REST/JSON-API erstellt, die von anderen Unternehmen (unseren Kunden) als B2B-Service verwendet wird. Jeder unserer Clients hat ein Benutzername/Passwort-Paar. Außerdem führen wir HTTPS durch und überprüfen die Quell-IP der Serviceanfragen. Die Nutzung des Dienstes kostet Geld, und dem Kunden wird monatlich die Nutzung des Dienstes in Rechnung gestellt.

Einige Kunden erstellen jetzt mobile Anwendungen, die sie ihren Benutzern (B2C-Endbenutzern) zur Verfügung stellen. Nicht alle dieser Endbenutzer unseres Dienstes haben Server und möchten den Dienst direkt vom Smartphone aus nutzen (was technisch gesehen keine große Sache ist, wenn es sich um JSON/REST handelt).

Das Problem ist, dass ich nicht sicher bin, wie ich den Dienst vor Betrug schützen soll. Was hindert einen Drittentwickler daran, eine mobile Anwendung des Kunden zu zerlegen und seinen Benutzernamen/sein Kennwort/die Sicherheitsanmeldeinformationen zu kopieren und diese in seiner Anwendung zu verwenden? Dies würde es ihm ermöglichen, den Service zu nutzen und die Nutzung einem unserer legitimen Kunden in Rechnung zu stellen!

Ich bin mir ziemlich sicher, dass es keine perfekte Kryptolösung für dieses Problem gibt, es sei denn, Endbenutzer müssen sich bei einem Server authentifizieren. Das ist aber nicht immer der Fall.

Als letzten Ausweg kann ich wohl eine verschleierte Bibliothek für Android/IPhone) verteilen, was zumindest die Illusion von Sicherheit vermitteln würde ...

EDIT (Klarstellung) :

Lassen Sie mich versuchen, das Szenario zu vereinfachen.

  1. Ich habe einen nicht hackbaren Webserver, der eine JSON REST API) bereitstellt.
  2. Mobile Clients greifen direkt auf meine API zu. Ihre IPs können nicht validiert werden. Sie verwenden ein Standardbetriebssystem (Android/IOS).
  3. Es sind keine anderen Server beteiligt.
  4. Ich kann nicht auf die IMEI des Telefons zugreifen (sie wird als privat betrachtet), und dies würde mir auch nicht helfen, da ich die Endbenutzer nicht kenne.
  5. Es gibt mehrere solcher legalen mobilen Anwendungen, die von verschiedenen Unternehmen entwickelt wurden und auf unsere API zugreifen.
  6. Die aktuelle Sicherheit (Benutzername/Passwort) kann von betrügerischen Unternehmen leicht gehackt werden. Diese betrügerische Firma zerlegt eine legitime mobile Anwendung und kopiert den Benutzernamen/das Passwort in ihre illegale Anwendung. Sie verteilen diese Anwendung und profitieren (die API-Nutzung wird dem Unternehmen in Rechnung gestellt, von dem sie die Anmeldeinformationen gestohlen haben).

Kann das gestoppt werden?

16
Tal Weiss

Ihre Frage lautet "Kann dies gestoppt werden?", Aber ich habe das Gefühl, dass alles, was am System von Bedeutung ist, nicht wirklich geändert werden kann/wird.

Wenn ich das richtig verstehe, fragen Sie (vereinfacht):

Ich habe viele Kunden, die denselben Benutzernamen und dasselbe Passwort verwenden. Kann ich den Missbrauch stoppen?

Die Antwort darauf lautet nein. Sie müssen entscheiden, ob Sie es sich leisten können, das Problem zu ignorieren oder korrekte Lösungen zu implementieren.

Wenn Sie dies wirklich richtig machen möchten, sollten Sie etwas wie OAuth implementieren, damit Sie separate Authentifizierungstoken für Endbenutzer ordnungsgemäß verteilen, sie zur Abrechnung mit Ihren Kunden verknüpfen, den Zugriff widerrufen usw. können.

- -

Das Mindeste, was Sie tun sollten, ist, Ihren Kunden (den Unternehmen) zu erlauben, sich für ein besseres Authentifizierungsschema zu entscheiden. So erstellen Sie beispielsweise eine API, über die sie separate Zugriffstoken für ihre Endbenutzer anfordern (und widerrufen) können.

  • Firma A fordert ein Token von ihren Servern an (dies wird von ihrer App initiiert, die ihnen sagt "Gib mir ein Token").
  • Sie geben Token N zurück und zeichnen auf, mit welcher Firma es verbunden ist
  • Wenn die App von Unternehmen A eine Verbindung zu Ihrem Dienst herstellt, sendet sie das Token N und nicht den Benutzernamen/das Kennwort
  • Unternehmen A kann Ihrem Dienst mitteilen, dass "Token N widerrufen" wird, und weitere Anforderungen mit diesem Token werden von Ihrem Dienst nicht bearbeitet. Wenn ein Token jedoch widerrufen wird, werden nicht alle Client-Apps unbrauchbar.

Wenn ein Unternehmen dies nicht möchte, kann es weiterhin mit seinem Benutzernamen/Passwort eine Verbindung herstellen, ist jedoch für die daraus resultierende Nutzung vollständig verantwortlich.

Der Punkt ist, dass Sie Ihre Kunden nicht wirklich für das Auslaufen von Anmeldeinformationen zur Rechenschaft ziehen können (was in einem Szenario mit mobilen Apps nicht möglich ist), wenn sie keine andere Möglichkeit haben, den Dienst zu nutzen.

7
Joel L

Also ich hoffe ich habe das richtig. Sie möchten eine sichere Methode zur Bestätigung der Identität eines Clients mithilfe eines gültigen API-Schlüssels? Ich denke, dass das sichere Speichern des API-Schlüssels weitgehend von dem Unternehmen abhängt, das die Anwendung entwickelt hat, und nicht von Ihrem Unternehmen.

Sie müssen den Schlüssel verschlüsseln und verschleiern, um ihn vor dem gelegentlichen Hacker zu schützen, aber ich glaube nicht, dass Sie jemals in der Lage sein werden, einen entschlossenen Hacker zu verhindern. Sie könnten ein bisschen Hacking betreiben, um das Debuggen der Binärdatei zu erschweren, wodurch die Wahrscheinlichkeit verringert wird, dass Ihre App im Internet schwebt. Dies ist jedoch keine absolute Sicherheit. Wie können Sie solche Maßnahmen durchsetzen, wenn Ihr Unternehmen die Anwendungen nicht intern entwickelt?

Als Antwort auf Ihr Szenario: Nein, ich glaube nicht, dass es effektiv gestoppt werden kann, ohne die Benutzererfahrung zu beeinträchtigen. Sie können die Unternehmen mithilfe Ihrer API schulen - stellen Sie ein kleines Handbuch für sie zusammen und stellen Sie sicher, dass klar ist, dass es ihre Verantwortung ist, ihre API-Schlüssel sicher zu halten.

Auf Ihrer Seite könnten Sie auch einige Schadensbegrenzungsfunktionen implementieren. Zum Beispiel:

  1. Ermöglichen Sie Unternehmen, ihre eigenen harten Grenzen zu definieren. Angenommen, Unternehmen A weiß, dass im letzten Monat N App-Downloads durchgeführt wurden, und möchte daher den Zugriff auf Ihre API auf X Anforderungen pro Tag oder Stunde beschränken.
  2. Überwachen Sie alle Spitzen bei Anfragen pro Unternehmen und Zeitraum.
  3. Definieren Sie einen Verfahrensschritt, der bei potenziellen betrügerischen Aktivitäten auftreten würde.
  4. Erneut eingeben, erneut eingeben und erneut eingeben.

Das Ziel beim Scheitern (es passiert am besten) ist es, den Schaden zu minimieren.

Viel Glück.

6
Kurt

Sie sind zu Recht skeptisch, wenn Ihre Kunden ihren Benutzernamen/ihr Passwort in eine mobile App einbetten, die sie an alle Benutzer weitergeben. Wie Sie richtig identifiziert haben, ist es für einige Angreifer einfach, diese mobile App zu zerlegen, den Benutzernamen/das Kennwort aus der mobilen App zu ziehen und sie in ihrer eigenen App zu verwenden. Leider ist Ihr Kunde derjenige, der darüber entscheidet, aber die Kosten werden Ihnen auferlegt. Dies ist also eine Externalität, und Sie benötigen eine Möglichkeit, um die Kosten, Risiken und Anreize besser aufeinander abzustimmen. Ich habe unten einige Vorschläge, wie das geht.

Generell sehe ich zwei plausible Lösungen dafür:

  • Risikotransfer. Legen Sie für jeden Kunden ein Limit für die Anzahl der Anfragen fest, die Sie von diesem Kunden annehmen. Teilen Sie den Kunden mit, dass es in ihrer Verantwortung liegt, ihren Benutzernamen/ihr Passwort sicher zu halten, dass alle Anfragen, die mit diesem Benutzernamen/Passwort eingehen, auf ihr Limit angerechnet werden. Wenn zu viele Anfragen eingehen, wird ihr Konto möglicherweise deaktiviert. Sagen Sie ihnen, dass beim Einbetten ihres Benutzernamens/Passworts in eine mobile App das Risiko besteht, dass jemand, der schändlich ist, den Benutzernamen/das Passwort stiehlt und damit viele Anfragen stellt, wodurch sein Konto deaktiviert wird und die mobile App nicht mehr funktioniert . Lassen Sie sie entscheiden, ob sie das Risiko eingehen wollen oder nicht.

  • Vertragliche Anforderungen. Teilen Sie Ihren Kunden mit, dass es ihnen untersagt ist, ihren Benutzernamen/ihr Passwort mit anderen zu teilen. Es ist ihnen nicht gestattet, ihren Benutzernamen/ihr Passwort in Apps einzubetten, die von anderen heruntergeladen werden können. Sagen Sie ihnen, dass ihr Konto möglicherweise deaktiviert wird, wenn Sie Verstöße gegen diese Richtlinie feststellen, und dass ihnen möglicherweise die Kosten in Rechnung gestellt werden, die dies Ihren Servern auferlegt.

    Wenn Ihre Kunden eine mobile App erstellen möchten, teilen Sie Ihren Kunden mit, dass sie, anstatt ihren eigenen Benutzernamen/ihr eigenes Passwort in die mobile App einzubetten, solche Anforderungen auf ihren eigenen Server übertragen sollten. Mit anderen Worten, der Client sollte einen Server einrichten, der den Benutzernamen/das Kennwort des Clients kennt. Dieser Benutzername/das Kennwort sollte jedoch nicht in die mobile App eingebettet sein. Die mobile App des Clients sollte sich beim Server des Clients authentifizieren, eine Anfrage an den Server senden. Anschließend sollte der Server die Anfrage an Sie weiterleiten und die Antwort an die mobile App zurückleiten. Ihr Server sollte den Endbenutzer authentifizieren (z. B. muss jeder Endbenutzer der mobilen App ein Konto auf seinem Server mit seinem eigenen Benutzernamen/Passwort erstellen). Ihr Server sollte Bandbreitenbeschränkungen pro Benutzer festlegen und das Konto aller Endbenutzer deaktivieren, die diese Beschränkungen überschreiten.

Sie können Clients auch erlauben, zwischen diesen beiden Optionen zu wählen: z. B. zwischen einem Konto mit begrenzter Bandbreite (mit Risikoübertragung) oder einem Konto mit unbegrenzter Bandbreite (mit der Anforderung, den Benutzernamen/das Kennwort nicht in Apps einzubetten, die für andere zugänglich sind ).

Ich hoffe das macht Sinn. Dies kann etwas verwirrend sein, da es drei Parteien gibt - Sie, Ihr Kunde und der Endbenutzer Ihres Kunden - jede mit ihren eigenen Interessen und Sorgen. Ich hoffe, ich habe alle drei angemessen unterschieden.

3
D.W.

Das Sichern Ihrer Daten bei der Übertragung mit SSL hat den Man-in-Middle-Angriff bereits abgedeckt. Passwörter, die im Quellcode fest codiert sind, sind sowieso keine sichere Praxis. Sie sollten sich nicht um die IP-Adresse von Benutzern oder IMEI kümmern. Lassen Sie uns nicht über Tracking sprechen und versuchen, die Probleme überhaupt zu beheben.

Wie Sie sagten, verwenden Sie REST. Ich hoffe, nur wenige Dinge sollten Ihnen helfen.

  1. Authentifizieren Sie die Benutzer von der Serverseite. Pflegen Sie strenge Sitzungsverwaltungen, damit diese nicht gefälscht werden können. Schauen Sie sich dazu OWASP an.
  2. Führen Sie einen Fuzz-Test für Ihre API durch. ReST ist für wenige Schwachstellen bekannt. Bitte erkunden Sie sie im Internet und lernen Sie die meisten bekannten Fehler in ReST kennen. Patchen Sie diese Probleme für Ihre API.
  3. Ihre SSL-Sache ist gut, dass sie Ihre Daten in der Mitte schützt.

Mach dir keine Sorgen über deinen Quellcode. Es kann sowieso herausgerissen werden, aber das ist in Ordnung. Ihre Hauptfunktionen müssen auf dem Server ausgeführt werden und nur die Antworten an die Clients weitergeben. Behalten Sie alle guten Dinge auf der Serverseite.

1
mojo

Eines der Probleme, mit denen Sie auf der mobilen Seite konfrontiert sein werden, ist die Überprüfung der IP-Adresse. In der Regel werden die von der Telekommunikation zugewiesenen mobilen IP-Adressen verrechnet. Die verrechnete IP macht den auf der Serverseite übernommenen IP-Validierungsmechanismus nutzlos.

Um die Lösung auf Android und Iphone's zu implementieren; ich denke, der Ansatz sollte sein:

  1. Lassen Sie die Client-Server-Authentifizierung im SSL-Modus auch auf die Client-Zertifikat-Validierung erweitern. Ich meine, Client und Server verwenden beide Zertifikate, um eine sichere SSL-Sitzung einzurichten.
  2. Stellen Sie den PFX/P12 mit dem Client-Zertifikat (mobil) so bereit, dass eine PIN und eine Kombination aus IMEI- und IMSI-Nummern) erforderlich ist. Auf diese Weise wird es für einen Angreifer schwierig, das zu verwerfen gleiche Sitzung.
  3. Lassen Sie eine KI auf dem Server implementieren, die zwei oder mehr gleichzeitige Sitzungen erkennt, die mit demselben Clientzertifikat initiiert wurden. Dadurch werden Sie darüber informiert, dass ein Kompromiss aufgetreten ist, und der Server kann das Zertifikat sofort auf die schwarze Liste setzen oder zur weiteren Verwendung widerrufen.

Ich glaube, obwohl wir über die mobile Umgebung diskutiert haben. Abgesehen von der IP-Validierung sind die Risiken auch in der PC-Umgebung vorhanden. In Zukunft können Sie auch eine signaturbasierte und auf Clientzertifikaten basierende Implementierung in einer PC-Umgebung übernehmen oder auf diese migrieren, wenn von Kunden falsche Abrechnungsprobleme auftreten.

1
Mohit Sethi

Betrug ist ein Maßstab und kann nicht nur durch eine technische Implementierung behoben werden. Wenn Sie jedoch eine eskalierte IP-Validierung und -Sperrung implementiert haben, brauchen Sie sich keine Sorgen zu machen. Sie dürfen Ihren Kunden auch nicht die tatsächlichen Anmeldeinformationen (B2B) geben. Lassen Sie mich erklären, warum und wie.

Nach meinem Verständnis dessen, was Sie geschrieben haben, wurden die grundlegenden bis durchschnittlichen Sicherheitskonzepte und -implementierungen bereits in Bezug auf die B2B-Seite (YOURCOMPANY - YOURCLIENT) angewendet. Das ist gut. IP-Validierung, SSL/TLS, Benutzer/Pass usw. Nun befürchten Sie, dass die API-Anmeldeinformationen, die Ihre Clients zur Bereitstellung mobiler Anwendungen für Endbenutzer verwenden, auf eine Weise fehlerhaft sein können, die ein Endbenutzer eines Drittanbieters nutzen würde Diese Anmeldeinformationen, wenn die mobile App Ihres Kunden auf irgendeine Weise ausgenutzt wurde.

Grundsätzlich läuft es auf eine Reihe von Sicherheitsebenen hinaus. Die Frage ist, wie Ihr Unternehmen diese Schichten entworfen und implementiert hat.

  1. Ihr JSON/REST-API-SERVER sollte Ihre tatsächlichen Anmeldeinformationen enthalten. Wenn Sie einen Dienst bereitstellen und eine Verbindung zu einem Netzbetreiber/Netzbetreiber benötigen, finden Sie diese Anmeldeinformationen auch hier. Du weißt was ich meine.

  2. Geben Sie IHREM KUNDEN keinen direkten Zugriff auf den JSON/REST-API-SERVER. Stattdessen benötigen Sie einen Sprunghost, der als Host für die vertrauenswürdige Umgebung dient. Der API-Server, von dem aus sich Ihre JSON/REST-Anwendung befindet, sollte sich NUR bei diesem Server mithilfe der Überprüfung/Sperrung der IP-Adresse authentifizieren. Server-zu-Server-Authentifizierung mithilfe von IP- oder öffentlichen/privaten Schlüsselpaaren. Es liegt in Ihrem Ermessen, was Sie verwenden möchten.

Dieser Server sollte auch als Webdienst fungieren, der eine Reihe von Benutzernamen/Kennwörtern enthält, die sich dann einer Konfigurationsdatei zuordnen und die Anforderung an den JSON/REST-API-SERVER weiterleiten. Jetzt sollten IHRE KUNDEN auch auf der Grundlage der IP-Validierung/-Sperrung Zugriff auf diesen Server haben und mit HTTPS geschützt sein. Das Konzept ist, dass hier keine tatsächlichen Benutzer-/Pass-Anmeldeinformationen gefunden werden können, außer dem Schlüssel/Geheimnis, das dem API-Server zugeordnet ist.

  1. IHR KUNDE kann eine Sicherheitsimplementierung von seiner Seite zu den Endbenutzern haben. Es kann in Form eines öffentlichen/privaten PKI-Schlüsselpaars für Entwickler oder eines 2FA für normale Benutzer vorliegen. IHR KUNDE sollte diese Schritte implementieren, nicht Ihr Unternehmen.

Jetzt hatte beispielsweise ein Entwickler eines Drittanbieters (Endbenutzer) einen Fehler in einer mobilen Anwendung ausgenutzt, die von einem IHREN KUNDEN erstellt wurde, und seine Anmeldeinformationen erhalten:

  1. Nutzlos. Um die Anmeldeinformationen verwenden zu können, wird Ihre IP-Adresse überprüft.
  2. Ungültig. Sie müssen über ein öffentliches/privates Schlüsselpaar authentifiziert worden sein.
  3. Bei der Eskalationstechnik für Berechtigungen muss er den tatsächlichen Server ausnutzen, um vertrauenswürdig zu sein.
  4. Das Ausnutzen des eigentlichen Servers erfordert handwerkliche Techniken, die die Motivation eines Angreifers verlangsamen.
  5. Es gibt keinen erfolgreichen Angriff, dessen Motivation beendet ist.

Die Verschleierung ist gut und verlangsamt einen Angriff, ist jedoch die geringste Form der Sicherheit. Sie sollten sich besser auf Krypto verlassen, das Schlüssel verwendet.

Denken Sie daran, dass es keine absolute Sicherheitslösung gibt, abgesehen von Ihren kontinuierlichen Bemühungen, Betrug aus technischer und betrieblicher Sicht zu bekämpfen.

1
John Santos