Frage:
API vor Manipulationen schützen?
VladiC4T
2020-06-01 00:35:57 UTC
view on stackexchange narkive permalink

Ich erstelle eine API mit Websocket, die Daten über JSON serialisiert. Die App selbst ist eine Chat-Anwendung. Ich habe mir die folgende Struktur ausgedacht, um meine Daten zu senden:

  {Datum: '2020-05-31', Uhrzeit: '14: 28: 05 ', Text: "Hey!", an: '<id: int>', von: '<id: int>'}  

Der Benutzer sendet grundsätzlich eine Nachricht über den Browser und diese wird auf einem Websocket-Server empfangen. Das von: 'id' stammt von dem Benutzer, der die Daten sendet, während das von: 'id' von dem Benutzer stammt, von dem die Daten gesendet werden.

Wenn ich das betrachte, habe ich ein sehr schlechtes Gefühl. Meine Gedanken; Der Benutzer, der die App verwendet, würde sich theoretisch authentifizieren und dort würde er seine ID erhalten. Dann hätte der Empfänger eine andere ID, so dass diese (offensichtlich) nicht mit der authentifizierten identisch ist. Der Server würde dann nach dieser ID suchen und die Nachricht senden, aber ich bin nicht sicher, ob dies sicher ist.

Ich habe einige Aspekte, die meiner Meinung nach korrekt behandelt werden müssen, um die App vor Angreifern zu schützen:

  • Was passiert, wenn der Angreifer beschließt, die " from: id" so zu manipulieren, dass er beliebige Nachrichten von jedem Benutzer an jeden senden kann?
  • Was Wenn der Angreifer ein Skript erstellt, das Millionen von Nachrichten spammt, indem er das Feld "to: id" nutzt?

Ist es möglich, dass ein anderes Sicherheitsproblem vorliegt? Ich mache mir keine Sorgen um?

Bitte verwenden Sie keine numerischen IDs.Vor allem nicht, wenn aufeinanderfolgend.Sie sollten kein System erstellen, in dem die Benutzer einfach aufgelistet werden können.Verwenden Sie stattdessen zufällige Zeichenfolgen.Wenn ich Benutzer 55 bin, wer ist Benutzer 54?Wenn ich Benutzer abfkg-4remq bin, ist abfkg-4remr höchstwahrscheinlich nicht einmal ein Benutzer. Als Angreifer kann ich daher nicht alle Benutzer-IDs leicht identifizieren
@stefan Dies ist nur relevant, wenn die Benutzeraufzählung eine Bedrohung darstellt.In vielen Szenarien ist dies nicht der Fall.
@vidarlo Vielleicht ist es meine begrenzte Vorstellungskraft, aber ich kann keine Szenarien sehen, in denen die Aufzählung von Benutzern von außen eine gute Sache ist.Sicher, intern haben Sie eine Datenbank mit allen Benutzern und das könnte notwendig sein, aber extern würde ich argumentieren, dass es fast immer ein Fehler ist.
Nicht sicherheitsrelevant, verwenden Sie jedoch das ISO-Format für den Zeitstempel (oder die Epoche).Dies erspart später viel Kopfschmerzen.Verwenden Sie auch eine gute, vollständige Bibliothek, um diese Zeit zu manipulieren (zum Beispiel ist die native Python-Übergabe der Zeit horrend (beurk), zum Glück gibt es Pfeil, Pendel, Dolorean).
Ein weiterer Grund, keine numerischen IDs zu verwenden, besteht darin, dass Zahlen in JS doppelt sind und daher für große Werte ungenau sind.
@AskarKalykov Da Sie in Ihrer Anwendung nicht mit IDs rechnen (ich weiß nicht, warum Sie das tun würden), ist es in der Praxis sehr unwahrscheinlich, dass Ungenauigkeiten auftreten.Sie hätten fast 2 ^ 53 IDs zur Verfügung, und das sind nur die positiven ganzzahligen.
@Ryan1729 Sie werden keine Mathematik machen, aber Sie möchten mit ziemlicher Sicherheit IDs weitergeben und möchten die richtigen IDs weitergeben.Es wäre nicht so toll, wenn Clients 404 oder 403 für legitime Anfragen erhalten würden, nur weil Backend-Entwickler beschlossen, Offsets für Identifikatoren und die Genauigkeit dieser IDs zu verwenden, da Doppelte über ganzzahlige Zahlen fielen.
@AskarKalykov 2 ^ 53 ist über 9 * Billiarden *.Sie hätten mehr als genug unterscheidbare IDs für alles Vernünftige.Sie weisen keinem Benutzer IDs außerhalb des ganzzahlensicheren Bereichs zu.Ich bin mir also nicht sicher, was Sie unter "Genauigkeit dieser IDs, wenn Doppelte über ganzzahlige Zahlen fallen" verstehen.Sie meinen, die Doppel sind präziser als nötig?Sind Sie besorgt über Fehler, die durch das Auftreten von Bruchdoppeln entstehen?
Wenn wir über Floats mit einfacher Genauigkeit gesprochen haben, ist es sicher schwierig, nur nicht 16 sequenzielle IDs zu haben, um sie nicht sequentiell zuzuweisen, und theoretisch könnten Sie davon ausgehen, aber das ist kein spezielles Problem bei Doubles.
@Ryan1729 Bitte schauen Sie sich die folgende Geige an, um zu verstehen, wovon ich spreche: https://jsfiddle.net/4ez675uf/ Wenn Sie json vom Backend erhalten, wissen Sie nicht einmal, dass ein Problem vorliegt.
@AskarKalykov Wie ich bereits erwähnt habe, liegt der Punkt, an dem dies geschieht, nach 9 Billiarden.Speziell bei 9.007.199.254.740.992.Siehe https://jsfiddle.net/koe3fsh1/. Weisen Sie einem Benutzer also niemals eine ID zu, die nicht zwischen 0 und 9007199254740991 liegt, und Sie können eine einfache serverseitige Überprüfung durchführen, um festzustellen, ob die ID innerhalb dieses Bereichs liegt, und ablehnenalles außerhalb davon.(Stellen Sie jedoch sicher, dass Sie mit NaNs richtig umgehen.) Dann können Sie jeden Bruchteil löschen und als ID verwenden, da eine Benutzer-ID kein Zugriffsschlüssel sein sollte.
Einfache Anführungszeichen sind nicht JSON.Sie werden von vielen Parsern akzeptiert, aber es ist nicht Teil des Standards.Datums- / Zeitfelder (wenn sie sich auf dieselbe Entität beziehen) sollten im ISO8601-Format (JJ-MM-TTTHH: MM: SSFFFZ) vorliegen, was bedeutet, dass es einfach ist, mit Standardbibliotheken zu erstellen / zu analysieren.
Acht antworten:
vidarlo
2020-06-01 00:41:51 UTC
view on stackexchange narkive permalink

Was passiert, wenn der Angreifer beschließt, die "from: id" so zu manipulieren, dass er beliebige Nachrichten von jedem Benutzer an jeden senden kann?

Erstellen Sie eine Sitzung und verwenden Sie die Sitzungskennung als Kennung, nicht die Benutzer-ID direkt. Z.B. Lassen Sie den Benutzer Anmeldeinformationen senden und geben Sie nach erfolgreicher Validierung ein (kurzlebiges) Sitzungshandle zurück, das in zukünftigen Nachrichten verwendet werden kann.

Überprüfen Sie, ob die Sitzung vorhanden und aktiv ist, und ordnen Sie sie dem Benutzerserver zu -side.

Was passiert, wenn der Angreifer ein Skript erstellt, das Millionen von Nachrichten spammt, indem er das Feld "to: id" nutzt?

Ratenlimit Benutzer serverseitig. Verbieten Sie beispielsweise das Senden von Nachrichten an mehr als zehn verschiedene Benutzer pro Minute. Dies wird legitime Benutzer wahrscheinlich nicht stören, aber die Bemühungen von Spammern behindern. Es kann offensichtlich erforderlich sein, das Limit zu optimieren - und es kann eine Idee sein, es für vertrauenswürdige Benutzer basierend auf dem Verhalten zu erhöhen und es zu senken, wenn Berichte über Spam von Benutzern eingehen.

Klingt großartig.Ich denke, eine andere Strategie in Bezug auf die Begrenzung, wer Nachrichten an wen senden kann, veranlasst den Benutzer, eine Art Einladungsanforderung anzunehmen, bevor der Absender Nachrichten senden kann, wie dies beispielsweise bei Skype der Fall ist.
Sicher.Oder haben Sie ein anfängliches Limit von 1-2 Nachrichten für neue Kontakte und erhöhen Sie es, wenn Benutzer aufeinander antworten.
Sockets sind eine konstante Verbindung. Es ist nicht erforderlich, den Absender bei jeder Nachricht zu identifizieren, da ohnehin nur der Absender über diese Verbindung senden kann.Sobald die Benutzer-ID überprüft wurde, ist keine sekundäre ID / Handle mehr erforderlich.
@dandavis das stimmt, aber mit mobilen Browsern scheint es, dass [es könnte einige Probleme mit diesem Ansatz geben] (https://github.com/primus/primus/issues/350).Daher ist eine Form der Sitzung möglicherweise keine schlechte Idee.
Der Angreifer erstellt nur 100000 Konten, von denen jede 10 Nachrichten pro Minute sendet.
@user253751, damit Sie die Kontoerstellung pro Quell-IP / Bereich / Standort / im Allgemeinen auf einen angemessenen Schwellenwert beschränken und optional ein Captcha in den Erstellungsprozess einfügen.Wenn Ihr App-Modell damit einverstanden ist, können Sie alternativ (oder zusätzlich) auf gemeinsam genutzte Anmeldedienste (Facebook) zurückgreifen oder eine Telefonnummer benötigen.Für einen kleinen Dienst ist es nicht notwendig, von Anfang an alles zu haben, aber er muss möglicherweise seine Verteidigungsfähigkeiten erweitern, wenn seine Popularität wächst.
Lukas
2020-06-01 00:52:50 UTC
view on stackexchange narkive permalink

Grundsätzlich müssen Sie jede Eingabe des Benutzers als potenziell bösartig behandeln.

Vidarlo hat in seiner Antwort bereits zwei Sicherheitsprobleme erwähnt und wie sie verhindert werden können.

Ich möchte auch hinzufügen, dass der Inhalt selbst ("text:") schädlichen Code enthalten kann (z. B. Javascript-Snippets). Stellen Sie sicher, dass dieser Code nicht auf der Empfangsseite ausgeführt wird.

Und ich würde auch prüfen, ob die Zeit korrekt erscheint. Abhängig von Ihrer Anwendung kann es nützlich oder sogar notwendig sein, verifizierte Zeitstempel zu haben.

Oh ja, Zeit.In meinem Fall würde es einfach für die Schnittstellenschicht dienen, nichts wirklich Besonderes.Kennen Sie zufällig Blogs / Ressourcen zur zeitlichen Nutzung?Ich bin interessiert, da Sie einige Probleme kennen, die auftreten können, wenn sie nicht richtig behandelt werden.
Eine Sache, an die ich denke, sind Einreichungsfristen, zum Beispiel für die Beschaffung.Wenn ein böswilliger Absender den Zeitstempel der Nachricht ändern kann, sieht es möglicherweise so aus, als ob die Nachricht vor Ablauf der Frist gesendet wurde (obwohl dies nicht der Fall war).Wie ich schrieb, kann dies ein Problem für Sie sein oder auch nicht.
Nehmen Sie die Zeitstempel heraus, Sie brauchen sie nicht, um Nachrichten zu belegen, sie können gefälscht werden, Sie wissen, wann sie trotzdem gesendet werden.
@dandavis können sie für die Leistungsanalyse der normalen Nutzung nützlich sein - wenn es keine andere Möglichkeit für den Kommunikationskanal gibt, den OP verwendet.Aber ja, es ist nicht gut, sich auf sie zu verlassen, wenn es um Sicherheit geht.
Oleg V. Volkov
2020-06-01 22:57:19 UTC
view on stackexchange narkive permalink

Was passiert, wenn der Angreifer beschließt, die "from: id" so zu manipulieren, dass er beliebige Nachrichten von jedem Benutzer an jeden senden kann?

Verwenden Sie nicht from: id in Ihre API. Sie kennen es bereits aus einer vom Benutzer authentifizierten Sitzung und haben keinen Grund für den Benutzer, es an Sie zu senden. Und wenn es nichts zu übertragen gibt, gibt es nichts zu manipulieren.

In diesem Sinne sollten Sie auch Datum und Uhrzeit wegwerfen. Sie wissen bereits, wann Sie eine Nachricht erhalten haben, und der Benutzer muss Ihnen dies nicht mitteilen. Sie benötigen diese nur, wenn Ihre Anwendung + API ein Konzept für Offline- / geplante / Backlog-Nachrichten hat.

Was ist, wenn der Angreifer ein Skript erstellt, das Millionen von Nachrichten spammt, indem er die " to: id "field?

Das ist ein ziemlich altes, sogar klassisches Problem, das andere, genauso alte Lösungen hat. Eine der einfachsten Möglichkeiten ist die Einführung eines Timeouts: Das Backend merkt sich, wann die Verwendung eine Nachricht gesendet hat, und kann erst nach Ablauf einer bestimmten Zeit etwas senden. Einige komplexere Lösungen beschränken sich immer noch darauf, den Benutzer auf eine bestimmte Anzahl von Nachrichten pro Zeitraum zu beschränken, verwenden jedoch zunehmend größere Verzögerungen, die mit der Zeit abnehmen, wenn mehr Nachrichten gesendet werden. Suchen Sie für einige nach "Drosselung" oder "Ratenbegrenzung" Beispiele und Ideen.

Ich sehe, dass Websocket den Status "Stateful" nutzt, aber mein Message-Dispatcher muss eine Absender-ID festlegen, damit der Empfänger weiß, wem diese Nachricht gehört.Wie würden Sie meinem Message-Dispatcher vorschlagen, den Ursprung der Nachricht zu kennen, indem Sie die ID entfernen?
Ich denke, ich müsste mich auf einen Session-Manager verlassen, um die vom Websocket-Client gesendete Sitzung einem Benutzer in einer Datenbank (wie Redis) zuzuordnen.
@VladiC4T Rufen Sie die API-Methode "authenticate" auf, bevor Sie Nachrichten senden, und verwenden Sie diese Sitzung.Sie benötigen es trotzdem, um zu verstehen, ob der Benutzer überhaupt die API verwenden darf und wer eine Nachricht senden darf.
Bestätigen;Meine "Authentifizierungs" -API prüft, ob Anmeldeinformationen vorhanden sind, und ordnet dem Benutzer dann eine Authentifizierungskennung zu.Dann würde mein Websocket-Server für jede vom Client gesendete Nachricht diese Authentifizierungskennung abrufen und auf den Benutzer verweisen?
OK habe es.Ich würde einfach die Websocket-Client-Verbindung verfolgen, die zuvor von meinem Authentifikator hergestellt wurde, und daher nur die Websocket-Sitzung verwenden.
@VladiC4T So ziemlich das.
Pedro
2020-06-01 15:51:38 UTC
view on stackexchange narkive permalink

Hier ist eine etwas alternative Ansicht, wie diese Probleme angegangen werden könnten. Ich gehe davon aus, dass Authentifizierung und Sitzungsverwaltung ordnungsgemäß implementiert sind.

Was passiert, wenn der Angreifer beschließt, die "from: id" so zu manipulieren, dass er beliebige Nachrichten von jedem Benutzer an jeden senden kann?

Wenn Sie zum Zeitpunkt der Erstellung für jeden "Chatroom" eine eindeutige (lange, zufällige, sehr schwer zu erratende, wie eine Sitzungskennung) Kennung generieren und sicherstellen, dass alle Parteien gerne beitreten In diesem Chatroom können Sie diese anstelle von Benutzerkennungen verwenden und steuern, welche Chatrooms jeder Benutzer senden kann, um sicherzustellen, dass andere keine Inhalte an die privaten Chats anderer Personen senden können. Ihre Nachrichten von den Benutzern X und Y werden also an Chatroom A gesendet und von der Anwendung weitergeleitet. Benutzer Z wurde nicht zugelassen, daher weigert sich die Anwendung, die Nachricht weiterzuleiten.

Was passiert, wenn der Angreifer ein Skript erstellt, das Millionen von Nachrichten spammt, indem er das Feld "to: id" nutzt?

Stellen Sie sicher, dass Nachrichten dies nicht können an Benutzer-IDs gerichtet sein und darauf hinarbeiten, dass Benutzer-IDs schwer zu erraten sind.

Barker1889
2020-06-01 19:36:17 UTC
view on stackexchange narkive permalink

Was passiert, wenn der Angreifer beschließt, die "from: id" so zu manipulieren, dass er beliebige Nachrichten von jedem Benutzer an jeden senden kann?

Eine andere Option besteht darin, jedem Benutzer eine Option zu geben eine Reihe von öffentlichen und privaten Schlüsseln. Diese können verwendet werden, um eine Signatur für jede Nachricht zu generieren, die überprüft, ob der Inhalt nicht manipuliert wurde und vom angegebenen Benutzer stammt.

Angenommen, Benutzer 1 möchte eine vereinfachte Nachricht an Benutzer 2 senden Prozess wäre:

  • Benutzer 1 erhält ein öffentliches / privates Schlüsselpaar. Sie (oder der Server) stellen ihren öffentlichen Schlüssel anderen Benutzern zur Verfügung.
  • Benutzer 1 erstellt den Nachrichteninhalt und generiert dann eine Signatur dafür mit ihrem eigenen privaten starker> Schlüssel (sie halten dies geheim)
  • Benutzer 1 sendet die Nachricht in einem Paket, das ungefähr so ​​aussieht wie
  {"Signatur": "kA7dagf4. .. ", Inhalt: {Datum: '2020-05-31', Uhrzeit: '14: 28: 05 ', Text:" Hey! "...  
  • Benutzer 2 empfängt die Nachricht und verwendet dann den öffentlichen Schlüssel von Benutzer 1, um zu überprüfen, ob der Nachrichteninhalt mit der Signatur übereinstimmt.

Der Schlüssel ist, dass der öffentliche Schlüssel nur verwendet werden kann Um die Signatur zu überprüfen, ist es nicht möglich, eine Signatur ohne den privaten Schlüssel zu erstellen.

Jeder böswillige Akteur, der sich als Benutzer 1 ausgeben und eine Nachricht an Benutzer 2 senden möchte, kann dies nicht, da dies nicht der Fall ist Sie können eine Signatur erstellen, die vom öffentlichen Schlüssel von Benutzer 1 überprüft wird. Benutzer 2 würde also sehen, dass die Signatur ungültig ist, und die Nachricht ablehnen können, wenn sie sie erhalten.

So funktionieren JSON-Web-Tokens ungefähr - ich würde empfehlen, dies für weitere Informationen nachzulesen - https://jwt.io/introduction/

Was passiert, wenn der Angreifer ein Skript erstellt, das Millionen von Nachrichten spammt, indem er das Feld "to: id" nutzt?

Wie in den vorherigen Antworten erwähnt, ist eine Kombination aus Ratenbegrenzung und schwer zu erratenden Feldern to: id und from: id schwer zu erraten.

Ein kleines Problem: Wo wird der private Schlüssel gespeichert?Wenn es auf dem Server gespeichert ist, kann es sich als Benutzer ausgeben.Selbst wenn es im Browser gespeichert ist, kann der Server bei Verwendung von JavaScript weiterhin darauf zugreifen.Wenn dem Server vertraut werden kann, scheint die Verwendung öffentlicher Schlüssel übertrieben.
Ich habe möglicherweise fälschlicherweise angenommen, dass es sich bei den Nachrichten um Peer-to-Peer-Nachrichten handelt.Wenn dem Server vertraut werden kann, sind die oben genannten Ideen zur Verwendung einer Sitzungskennung der einfachste Weg, dies zu lösen.
Iain
2020-06-01 09:22:19 UTC
view on stackexchange narkive permalink

Es liegt auf der Hand, dass die Daten nicht verschlüsselt sind. Sie haben bereits Manipulationen erwähnt und häufig werden Verschlüsselung und Integrität gleichzeitig behandelt, da Sie durch Verschlüsselung ohne Integrität immer noch für Angriffe offen sind

Fügen Sie einen MAC (Nachrichtenauthentifizierungscode) für hinzu die Daten. Einige Verschlüsselungsmodi wie GCM (Galois / Counter Mode) enthalten einen, andere sind separat, sodass Sie HMAC möglicherweise mit etwas anderem verwenden. Töte 2 Fliegen mit einer Klappe oder benutze einfach 2 Steine. Schützt dies den Benutzer jedoch vor Angriffen auf Ihrer Seite der API? Sie müssen darüber nachdenken, was passiert, wenn Sie ebenfalls kompromittiert werden.

Möglicherweise sehen Sie sich andere Arten von APIs an und sehen, wie sie Arten von Angriffen abschwächen. Beispielsweise verwendet OAuth 2 aus unterschiedlichen Gründen einen Statusparameter und eine Nonce. Wie bei der Antwort von @ vidarlo können Sie eine Nonce in Kombination mit der Sitzungs-ID verwenden.

Websockets sind wie https trivial verschlüsselt und haben eine integrierte Integrität.Es ist auch keine Sitzung erforderlich, da es sich nicht um einen Anforderungs- / Res-Zyklus handelt, sondern um eine konstante Verbindung.
@dandavis Ich verstehe Ihren Standpunkt, aber sie sind zwischen dem Client und dem Server verschlüsselt, nicht zwischen Client und Endempfänger. Deshalb habe ich den Teil über "Ihre Seite der API" hinzugefügt.Sie haben Recht mit der Sitzungs-ID, die nur während der Verbindungsaufbauphase benötigt wird, aber [Websockets können über CORS entführt werden] (https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html)Ein Teil über OAuths Statusparameter ist ebenso relevant wie die Verwendung einer Sitzungs-ID.Als Benutzer möchte ich wissen, dass meine Nachricht richtig ans andere Ende gelangt, nicht nur an den Server.
Die Client-zu-Server-Verschlüsselung ist der wichtige Teil.Die Verschlüsselung von Client zu Endempfänger ist nur dann wichtig, wenn es tatsächlich darauf ankommt, und je nach Anwendungsfall ist eine End-to-End-Verschlüsselung oft nicht die Mühe wert oder hilfreich.
@ConorMancone "Die Verschlüsselung von Client zu Endempfänger ist nur dann wichtig, wenn es tatsächlich darauf ankommt" - arbeiten Sie für eine 3-Buchstaben-Agentur oder einen Werbetreibenden?Ansonsten macht Ihre Aussage keinen Sinn.
@Iain Wie wäre es mit einem Messaging-System in einem CRM?Oder eine Business-Software-Suite?Oder eine beliebige Anzahl von Anwendungen außerhalb der Kommunikation von Person zu Person?Es gibt immer mehr Anwendungsfälle als den, an den Sie denken, weshalb es eine schlechte Idee ist, allgemein fast alles zu empfehlen.Es gibt viele Fälle, in denen E2E die Mühe nicht wert ist, und weitere Fälle, in denen es den geschäftlichen Anforderungen widerspricht
@ConorMancone Aus der Frage: "Die App selbst ist eine Chat-Anwendung".E2E ist mittlerweile als * vernünftige * Funktion für Chat-Apps etabliert, vielleicht sogar als Standard - sogar Facebook Messenger plant, darauf umzusteigen, wenn die Aktionäre dies nicht tun.Die Priorisierung von Geschäftsanforderungen ist eine gute Sache, und ob dies eine hohe Priorität hat oder nicht oder sogar im Widerspruch zu Geschäftsanforderungen steht, ist umstritten, aber dies ist ein Sicherheitsforum.
Es gibt sicherlich viele Fälle, in denen eine E2E-Verschlüsselung erforderlich ist.Ich argumentiere das nicht.Auch hier habe ich Chat-Anwendungen für Unternehmenssoftware erstellt, bei denen Sie definitiv keine E2E-Verschlüsselung wünschen.Ich kann mir auch einige Anwendungsfälle in Nur-Verbraucher-Systemen vorstellen, in denen die E2E-Verschlüsselung nicht Ihren Wünschen entspricht.Mein Punkt ist, dass wie bei allen Sicherheitsaspekten hier eine ordnungsgemäße Risikoanalyse und das Verständnis Ihres Anwendungsfalls wichtig sind.Die E2E-Verschlüsselung ist nicht in allen Fällen relevant, auch wenn sie in vielen Fällen relevant ist.
-1 da es sich um ein berechtigtes Anliegen handelt, handelte es sich bei der tatsächlich gestellten Frage um einen böswilligen ** Benutzer ** (Alice), nicht um einen böswilligen Vermittler (Eve).
@Tom "Die eigentliche Frage betraf einen böswilligen Benutzer." Nein, das ist ein Beispiel."Um die App vor jedem Angreifer zu schützen", heißt es in der Frage.Du kannst diese Abstimmung jetzt zurückstellen ;-)
@Iain Ich habe die Frage erneut gelesen und sehe keine Besorgnis des OP über MitM oder andere ** Kanal ** -Angriffe.Ich denke immer noch, dass er sich mit Datenstrukturen befasst.
@Tom Wie haben Sie nicht gesehen, "um die App vor *** jedem *** Angreifer zu schützen"?Oder * Was ist, wenn der Angreifer ein Skript erstellt, das Millionen von Nachrichten spammt, indem er das Feld "to: id" nutzt? * Wie ist das mit * nur * der Datenstruktur?Es ist nicht so, dass eine Ratenbegrenzung eine völlig normale Abschwächung wäre, die die Datenstruktur des Anrufers nicht beeinflusst.
@Iain Ich glaube immer noch nicht, dass MitM im Rahmen der Frage liegt, aber ich werde dem den Vorteil des Zweifels geben.
@Tom Sehr großmütig von Ihnen, und ich respektiere, dass Sie an Ihrer Meinung festhalten.
Tom
2020-06-02 14:45:07 UTC
view on stackexchange narkive permalink

Ihr Ansatz enthält zahlreiche Sicherheitsprobleme, auf die die meisten bereits in anderen Antworten hingewiesen wurden.

Ich möchte mit allgemeinen Grundsätzen antworten, die Ihnen helfen, diese Probleme selbst zu finden.

Behandeln Sie alle vom Benutzer bereitgestellten Daten als böswillig.

Alles, was von einem Client kommt, ist nicht vertrauenswürdig. Es braucht Eingabevalidierung, Trimmen, Entkommen, die ganzen neun Meter. In Ihrem Fall sendet Ihre App wahrscheinlich den richtigen JSON. Was passiert jedoch in Ihrer API, wenn jemand einen JSON von Hand erstellt und Ihnen ungültigen JSON gibt, den String nicht beendet oder die SQL-Injection dort mischt?

Nehmen Sie niemals Eingaben für Daten vor, die Sie bereits haben.

Wie in anderen Antworten angegeben. Sie kennen bereits Datum / Uhrzeit und die "Von" -ID. Akzeptieren Sie sie daher nicht als Eingang. Akzeptieren Sie im Allgemeinen niemals Eingaben zu etwas, das Sie von einer vertrauenswürdigeren Quelle erhalten können.

SWIFT-Ansatz

Gehen Sie jedes Element durch und fragen Sie sich, "was möglicherweise schief gehen könnte?". SWIFT ( hier oder mehrere andere Quellen) ist eine strukturierte Methode, um dies zu tun. Wenn Sie Ihre Eingabe auf Text und ID reduziert haben, sollten Sie sich überlegen, wie jemand diese missbrauchen könnte. Könnte er falsche Daten senden, zu wenig Daten, zu viele Daten? Dieser Ansatz sollte Sie auf die in anderen Antworten beschriebenen Bedrohungen wie Aufzählung, Überflutung / Spam usw. aufmerksam machen.

Betrachten Sie Ihr Backend-System

und kennen Sie schließlich die Schwächen Ihres Backend-Systems . Wenn Sie eine SQL-Datenbank hinter sich haben, überlegen Sie, ob es Möglichkeiten für die SQL-Injection gibt. Denken Sie auch an Leistung und Systembeschränkungen. Kann ein Benutzer möglicherweise so viele Daten senden, dass Ihre E / A, Ihre Verarbeitung oder Ihre Speicherkapazität überfordert sind? Kann er die API für andere Benutzer blockieren (was sind Ihre Grenzen für die parallele Verarbeitung? Wie viele Verbindungen können Sie verarbeiten usw.)?

Obwohl dies kein vollständiger Ansatz zur Bedrohungsmodellierung ist, finde ich, dass er zu 90% so gut ist mit einem kleinen Teil der vollen Anstrengung.

"Kennen Sie die Schwächen Ihres Backend-Systems."Ich würde das generell auf das gesamte System ausweiten.Beispielsweise können andere Benutzer im Frontend für Cross-Site Scripting (XSS) anfällig sein.
Garandy
2020-06-02 23:15:48 UTC
view on stackexchange narkive permalink

Regel 0: Vertraue niemals dem Kunden. Überprüfen Sie unter allen Umständen alle Eingaben von der Clientseite.

In diesem Fall bedeutet dies, dass überprüft wird, ob der sendende Benutzer (a) als derjenige authentifiziert ist, von dem er behauptet, die Nachricht zu senden, und (b) autorisiert ist um eine bestimmte Nachricht basierend auf Ihren Kriterien zu senden. Dies bedeutet auch, dass das Feld "Text" bereinigt werden muss, bevor es gespeichert oder angezeigt wird, und dass der Zeitstempel für die Sendezeit vom Server festgelegt werden sollte - für Ihr System wurde eine Nachricht nur dann "gesendet", wenn Das System hat es vom Absender erhalten.

Nachdem Sie die Teile des Modells abgeschnitten haben, die der Server für den Benutzer ausfüllen kann (und sollte), haben Sie nur die Empfänger-ID und die Nachricht Inhalt.

In Bezug auf die Aufzählung der Benutzerliste mithilfe von sequentiellen IDs und / oder Spam gibt es mehrere Möglichkeiten, dies zu handhaben, z. B. eine "Freundschaftsanfrage" (per E-Mail, Telefon, Benutzername, usw.) System, das Benutzer darauf beschränkt, nur Nachrichten an vorautorisierte Empfänger senden zu können, und keinen Hinweis darauf gibt, ob das Ziel einer Freundschaftsanfrage ein tatsächlicher Benutzer im System ist. Darüber hinaus können Sie herkömmliche Ratenbegrenzungen mit so etwas wie einem undichten Eimer durchführen oder sogar ein Überwachungssystem erstellen, das Benutzer mit Hochwasser- / Spam-Verhalten kennzeichnet / verbietet.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...