it-swarm.com.de

Clientseitige Codierung: Wie kann eine böswillige Verwendung verhindert werden?

In den letzten Jahren hat der Trend zu clientseitigen (Browser-) Anwendungen stark zugenommen.

Für mein letztes Projekt habe ich mich entschlossen, mit der Zeit zu gehen und eine clientseitige Anwendung zu schreiben.

Ein Teil dieser Anwendung umfasst das Senden von Transaktions-E-Mails an Benutzer (z. B. Überprüfen der Anmeldung, Zurücksetzen von Kennwörtern zum Zurücksetzen des Kennworts usw.). Ich verwende eine Drittanbieter-API, um die E-Mails zu senden.

Normalerweise würde meine Anwendung auf einem Server ausgeführt. Ich würde die Drittanbieter-API über Code auf meinem Server aufrufen.

Das Ausführen einer clientseitigen Anwendung bedeutet, dass dies jetzt im Browser eines Benutzers erfolgen muss. Die Drittanbieter-API stellt die erforderlichen JavaScript-Dateien bereit, um dies zu erreichen.

Das erste krasse Problem, das ich sehe, ist, dass ich einen API-Schlüssel verwenden muss. Dies wird normalerweise sicher auf meinem Server gespeichert, aber jetzt muss ich diesen Schlüssel vermutlich dem Client-Browser zur Verfügung stellen.

Angenommen, ich kann dieses Problem umgehen, ist das nächste Problem, das einen technisch versierten Benutzer davon abhält, das JavaScript-Entwicklertool in einen Browser zu laden und die E-Mail-API zu verwenden, wie er möchte, anstatt zu sagen, dass ich die in der Anwendung festgelegten Regeln einhalte .

Ich denke, meine allgemeine Frage lautet: Wie können wir die böswillige Verwendung einer clientseitigen Anwendung verhindern?

60
Gaz_Edge

Sie können nicht, und je mehr Menschen dies verstehen und je tiefer sie verstehen, desto besser für die Welt.

Code, der auf einem Gerät ausgeführt wird, das vom Benutzer gesteuert wird, kann nicht gesteuert werden. Smartphones können einen Jailbreak haben. Set-Top-Boxen können geknackt werden. Normale Browser versuchen nicht einmal, den Zugriff auf JavaScript-Code zu verhindern. Wenn Sie etwas haben, das es wert ist, gestohlen oder missbraucht zu werden, kann ein entschlossener Angreifer wird dies tun, es sei denn, Sie validieren alles, was Sie serverseitig schätzen.

Verschleierung ist sehr wenig hilfreich; Die Art von Gegner, die Sie anziehen werden, sobald es sich um eine finanzielle Angelegenheit handelt, lautet Assemblersprache wie Kleinanzeigen. Die Verschlüsselung kann Ihnen nicht helfen, da das Gerät, das den Schlüssel schützen würde, dasselbe Gerät ist, von dem Sie annehmen müssen, dass es geknackt ist. Es gibt viele andere, scheinbar offensichtliche Gegenmaßnahmen, die aus ähnlichen Gründen nicht funktionieren.

Leider ist dies eine sehr unbequeme Wahrheit. Die Welt ist voll von kleinen und großen Betreibern, die glauben, sie könnten die grundlegende Zerbrochenheit des Remote-Vertrauens irgendwie umgehen, einfach weil es oh so schön wäre, wenn wir davon ausgehen könnten, dass unsere Der Code wird so ausgeführt, wie wir es angenommen haben. Und ja, es würde alles so viel einfacher machen, dass es nicht einmal lustig ist. Aber das Wünschen macht es nicht so, und die Hoffnung gegen die Hoffnung, dass Sie der einzige kluge Keks sind, der die Unannehmlichkeiten vermeiden kann, wird Sie und Ihre Kunden nur verbrennen. Denken Sie daher daran, dass das Internet ein feindliches Gebiet ist, nehmen Sie diese zusätzlichen Kosten in Ihre Schätzungen auf, und es wird Ihnen gut gehen.

Das heißt, natürlich gibt es so etwas wie Tiefenverteidigung. Das Verschleiern Ihres JavaScript schreckt einen entschlossenen Angreifer nicht ab, kann jedoch einige weniger entschlossene Angreifer abschrecken. Wenn Ihr Vermögen zum Schutz ausreichend ist, jedoch nicht um jeden Preis, kann eine dieser Maßnahmen Ihrem System einen geschäftlichen Mehrwert verleihen. es kann einfach nicht perfekt sein. Solange Sie sich des Kompromisses, den Sie eingehen, voll bewusst sind, kann dies eine vernünftige Strategie sein.

200
Kilian Foth

Die Regel hier ist:

Machen Sie alles clientseitig, was niemanden betrifft, wenn der Benutzer damit manipuliert. Dies bedeutet insbesondere grafische Effekte.

Machen Sie alles serverseitig, was sicher sein muss, und senden Sie einfach UI-Ereignisse vom Client (z. B. sagt der Client nur "der Benutzer hat auf die Schaltfläche" Kaufen "getippt", während der Server die Transaktion tatsächlich ausführt). Dies bedeutet insbesondere Finanztransaktionen.

69
jhocking

Dies ist genau der Fall, wenn es nicht angemessen ist, es zu einer vollständig clientseitigen Anwendung zu machen.

Sie können die Logik und die grundlegende Validierung von Formularen clientseitig durchführen (Sie müssen sie auf dem Server noch einmal validieren, da möglicherweise jemand versucht, die Anforderung zu fälschen), um die Reaktionsfähigkeit zu verbessern. Sie können HTTP-Anforderungen von JavaScript ausführen, indem Sie Daten hin und zurück in JSON an JSON übergeben Vermeiden Sie das erneute Senden von Seitendekorationen und dergleichen. Wenn die Transaktion selbst authentifiziert und autorisiert werden muss, sollte dies dennoch auf einem Server geschehen.

28
Jan Hudec

Ihr mittlerer Absatz ist das Herzstück des Problems:

Das Ausführen einer clientseitigen App bedeutet, dass dies jetzt in einem Benutzerbrowser erfolgen muss. Die Drittanbieter-API stellt die erforderlichen JS-Dateien bereit, um dies zu erreichen.

Warum bedeutet eine clientseitige App, dass Sie nicht serverseitig arbeiten können? Beim Vorstoß zur clientseitigen Programmierung geht es nicht darum, Server zu eliminieren, sondern neuere Technologien zu nutzen, die Browser schließlich unterstützen, um bessere Benutzeroberflächen zu schaffen.

Wie für die .js Datei, die Sie erhalten haben, sind Sie sicher, dass sie für einen Browser gedacht ist? Könnte es eine node.js-Bibliothek sein?

17
Brandon

Lassen Sie uns einen Schritt zurücktreten und einen Blick auf eine höhere Ebene werfen. Sollen wir ... Haben Eudora oder Outlook (eine clientseitige App, die nicht einmal einen Browser benötigt) jemals einen finanziellen Verlust für ein Unternehmen verursacht? Nein. Jeder kann in die POP/SMTP-APIs schreiben und der Client sein. Aber kein Verlust für den Server. Der Server hat die Clientaktionen, Berechnungen, Speicher, Temperatur, Festplattengröße, RAM-Größe, Monitor-DPI, GPU, FPU yada yada des Clients nicht eingeschränkt, sondern genau angegeben, worauf er antworten würde, und nicht mehr. Haben Sie jemals davon gehört, dass Quicken oder MS-Money verwendet werden, um zu einer Bank zu brechen?

Ihre Browser-App (d. H. Client-seitige App) kann dieselbe Architektur verwenden.

  1. Sie erstellen Ihren Server mit einer API (die übrigens immer auf Ableitungen von GET POST HEAD usw.) hinausläuft).
  2. Stellen Sie auf dem Server sicher, dass die API bei jedem Aufruf nur mit einem authentifizierten und identitätsgeprüften Client kommuniziert.
  3. Dann ist es dir egal, wer der Kunde ist.
  4. Und dann ist es Ihnen egal, ob es sich um einen Browser, ein Gerät mit Jailbreak, Google Glass, DOS 3.1 oder ein brandneues Nexus in den Händen eines technikbegeisterten Ur-Ur-Ur-Ur-Großvaters handelt, der die Zeit bis 2014 verbracht hat und alles verpasst hat Die Technologie, die unser Leben in den letzten 15 Jahrzehnten überschwemmt hat.
  5. Jetzt können Sie alles andere auf die Clientseite verlagern.

SoapBoxBegin

@KilianFoth macht die Naiven und Rücksichtslosen auf sich aufmerksam, vor allem diejenigen, die ständig die Schlagzeilen lesen, aber nie glauben, dass dies ihrer App, ihrem Code, ihrem Arbeitgeber, ihrem Kunden oder ihrem eigenen Bankkonto passieren wird. Noch rücksichtsloser sind ihre Arbeitgeber (insbesondere die CTOs), die es Apps ermöglichen würden, herauszukommen, die alle Systeme einer nicht verwalteten/unkontrollierten Gefährdung aussetzen. Ich bin jedoch immer verwirrt darüber, wie es scheint, "wir lernen nie".

SoapBoxEnd

Also um es zusammenzufassen. Erstellen Sie eine solide und straffe serverseitige API. Laden Sie alles andere auf den Client herunter, je nachdem, was der Client verarbeiten kann.

11
LMSingh

Ich würde argumentieren, dass Sie wirklich nicht können. Wenn Sie bereit sind, die Daten an den Kunden zu senden, müssen Sie damit rechnen, dass sie missbraucht werden - wie auch immer möglich. Ihr Beispiel bezüglich des API-Schlüssels veranschaulicht den Punkt, und ich würde das nicht in Ihre clientseitige JS aufnehmen - es wird gestohlen und missbraucht.

Sie werden definitiv noch eine Menge Servercode benötigen, um die Sicherheit zu gewährleisten. Sogar etwas so Einfaches wie das Abrufen nur der Daten, die sich auf den angemeldeten Benutzer beziehen. Diese Authentifizierung kann nicht alle clientseitig erfolgen, oder Sie werden erneut ausgenutzt und Ihre Daten sind nicht sicher.

Ich würde die JS-clientseitige Erfahrung immer als Ergänzung zum Servercode betrachten. Die Validierung auf dem Client bietet eine gute Benutzererfahrung. Wenn Sie jedoch nicht überprüfen, ob POST Daten auch auf dem empfangenden Server vorhanden sind, öffnen Sie sich für Angriffe. Alles vom Client sollte es sein als verdächtig angesehen.

6
Matt Klinker

Es ist wirklich ganz einfach. Angenommen, der Client-Computer und die gesamte darauf ausgeführte Software stehen unter der vollständigen Kontrolle eines cleveren böswilligen Hackers.

Das bedeutet, dass alle Informationen, die Sie vom Server an den Client senden, dem böswilligen Hacker bekannt sind. Sie müssen daher sicherstellen, dass keine Informationen an den Client gesendet werden, die zum Angriff auf Ihren Server oder Ihr Unternehmen verwendet werden könnten.

Dies bedeutet auch, dass alles, was vom Client an den Server gesendet wurde, vom böswilligen Hacker erstellt wurde. Daher muss Ihr Servercode sicherstellen, dass nichts, was der Client senden kann, Ihren Server erfolgreich angreifen kann.

Zugegeben, die Implementierung ist ein Problem, aber das Wichtigste ist die mentale Einstellung, die Annahme, dass der "Client", mit dem Ihr Server zu sprechen glaubt, kein Client, sondern ein aktiver Angreifer ist.

(Sie müssen auch davon ausgehen, dass der Benutzer ein kluger Betrüger ist, der versucht, Ihre Geschäftsmethoden anzugreifen, aber das hat nichts mit clientseitiger Programmierung zu tun.).

4
gnasher729

Bei der clientseitigen Anwendung geht es meiner Meinung nach hauptsächlich um die Benutzeroberfläche. Zum Beispiel wird Ihr gesamtes UI-System einmal an den Client gesendet, und dann würde der Client damit machen, was er will.

Normalerweise würde meine Anwendung auf einem Server ausgeführt. Ich würde die Drittanbieter-API über Code auf meinem Server aufrufen.

Das Ausführen einer clientseitigen Anwendung bedeutet, dass dies jetzt im Browser eines Benutzers erfolgen muss. Die Drittanbieter-API stellt die erforderlichen JavaScript-Dateien bereit, um dies zu erreichen.

Wenn Sie einen API-Schlüssel haben, ist dieser nicht für die Client-Seite vorgesehen. Wenn Sie den API-Schlüssel auf der Clientseite angeben, hat jeder Zugriff darauf und kann ihn dann für seinen eigenen Zweck verwenden. Speichern Sie es und verwenden Sie es serverseitig, wenn der Client es benötigt. Senden Sie das Ergebnis dann mit Ajax/WebSockets.

Es ist, als würde Ihre Bank sagen: "Nun, ich werde das Passwort der Client-Seite der Hauptdatenbank eingeben, damit der Client es selbst anfordern kann und unsere Server nicht mehr belästigt."

0
Depado