Kann lokaler Speicher jemals als sicher angesehen werden? [geschlossen]

160

Ich muss eine Webanwendung entwickeln, die über einen längeren Zeitraum offline funktioniert. Damit dies möglich ist, kann ich es nicht vermeiden, sensible Daten (persönliche Daten, aber nicht die Art von Daten, die Sie nur als Hash speichern würden) im lokalen Speicher zu speichern.

Ich akzeptiere, dass dies keine empfohlene Vorgehensweise ist, aber wenn ich keine andere Wahl habe, gehe ich wie folgt vor, um die Daten zu sichern:

  • Verschlüsselung aller Daten, die in den lokalen Speicher gelangen, mithilfe der Stanford-Javascript-Kryptobibliothek und AES-256
  • Das Benutzerkennwort ist der Verschlüsselungsschlüssel und wird nicht auf dem Gerät gespeichert
  • Bereitstellung aller Inhalte (wenn online) von einem einzigen vertrauenswürdigen Server über SSL
  • Überprüfen aller Daten, die zum und vom lokalen Speicher auf dem Server gehen, mithilfe des Owasp-Antisamy-Projekts
  • Verwenden Sie im Netzwerkbereich des Appcaches nicht * und listen Sie stattdessen nur die URIs auf, die für die Verbindung mit dem vertrauenswürdigen Server erforderlich sind
  • Im Allgemeinen wird versucht, die im OWASP XSS-Spickzettel vorgeschlagenen Richtlinien anzuwenden

Ich weiß zu schätzen, dass der Teufel oft im Detail steckt, und weiß, dass die lokale Speicherung und die auf Javascript basierende Sicherheit im Allgemeinen sehr skeptisch sind. Kann jemand kommentieren, ob es gibt:

  • grundlegende Mängel im obigen Ansatz?
  • Gibt es mögliche Lösungen für solche Mängel?
  • Gibt es eine bessere Möglichkeit, den lokalen Speicher zu sichern, wenn eine HTML 5-Anwendung für längere Zeit offline funktionieren muss?

Vielen Dank für jede Hilfe.

user1173706
quelle
"Ich akzeptiere, dass dies keine empfohlene Übung ist" - Ist es so? Ist es nicht das Gegenteil, dass es tatsächlich dafür geschaffen wurde?
hakre
2
Zur Verdeutlichung habe ich nicht empfohlen, vertrauliche Daten im lokalen Speicher zu speichern .
user1173706
So sollten Sie sensible Daten nicht über große Netzwerke weitergeben?
hakre
@ user1173706 Warum muss die Anwendung funktionieren, um über einen längeren Zeitraum offline ausgeführt zu werden? Wie sind die Benutzer? Welche Browser müssen Sie unterstützen? Ich denke, es ist möglich, aber ich muss Einzelheiten über Ihr Szenario wissen .
Benjamin Gruenbaum
@ Benjamin Ich habe die Frage aktualisiert. Vielen Dank.
user1173706

Antworten:

74

WebCrypto

Die Bedenken hinsichtlich der Kryptografie in clientseitigem (Browser-) Javascript werden nachstehend erläutert. Alle bis auf eines dieser Probleme gelten nicht für die WebCrypto-API , die jetzt einigermaßen gut unterstützt wird .

Für eine Offline-App müssen Sie weiterhin einen sicheren Keystore entwerfen und implementieren.

Nebenbei: Wenn Sie Node.js verwenden, verwenden Sie die integrierte Krypto- API.

Native-Javascript-Kryptographie (vor WebCrypto)

Ich gehe davon aus, dass das Hauptanliegen jemand ist, der physischen Zugriff auf den Computer hat, der die Informationen localStoragefür Ihre Site liest , und Sie möchten, dass Kryptografie dazu beiträgt, diesen Zugriff zu verhindern.

Wenn jemand physischen Zugang hat, sind Sie auch offen für andere und schlimmere Angriffe als das Lesen. Dazu gehören (ohne darauf beschränkt zu sein): Keylogger, Offline-Skriptänderung, lokale Skriptinjektion, Browser-Cache-Vergiftung und DNS-Weiterleitungen. Diese Angriffe funktionieren nur, wenn der Benutzer den Computer verwendet, nachdem er kompromittiert wurde. Der physische Zugriff in einem solchen Szenario bedeutet jedoch, dass Sie größere Probleme haben.

Denken Sie also daran, dass das begrenzte Szenario, in dem lokale Krypto wertvoll ist, darin besteht, dass der Computer gestohlen wird.

Es gibt Bibliotheken, die die gewünschte Funktionalität implementieren, z. B. die Stanford Javascript Crypto Library . Es gibt jedoch inhärente Schwächen (wie im Link aus der Antwort von @ ircmaxell erwähnt):

  1. Fehlende Entropie- / Zufallszahlengenerierung;
  2. Fehlen eines sicheren Schlüsselspeichers, dh der private Schlüssel muss passwortgeschützt sein, wenn er lokal oder auf dem Server gespeichert ist (wodurch der Offline-Zugriff gesperrt wird).
  3. Mangel an sicherer Löschung;
  4. Fehlende Timing-Eigenschaften.

Jede dieser Schwächen entspricht einer Kategorie kryptografischer Kompromisse. Mit anderen Worten, während Sie vielleicht "Krypto" mit Namen haben, wird es weit unter der Strenge liegen, die man in der Praxis anstrebt.

Abgesehen davon ist die versicherungsmathematische Bewertung nicht so trivial wie "Javascript-Krypto ist schwach, verwenden Sie es nicht". Dies ist keine Bestätigung, sondern eine Einschränkung. Sie müssen die Aufdeckung der oben genannten Schwachstellen, die Häufigkeit und die Kosten der Vektoren, mit denen Sie konfrontiert sind, sowie Ihre Fähigkeit zur Schadensbegrenzung oder Versicherung im Falle eines Fehlers vollständig verstehen: Javascript crypto, in Trotz seiner Schwächen kann Ihre Exposition verringert werden, jedoch nur gegen Diebe mit begrenzter technischer Kapazität. Sie sollten jedoch davon ausgehen, dass Javascript-Krypto keinen Wert gegen einen entschlossenen und fähigen Angreifer hat, der auf diese Informationen abzielt. Einige würden es für irreführend halten, die Daten als "verschlüsselt" zu bezeichnen, wenn bekannt ist, dass der Implementierung so viele Schwachstellen inhärent sind. Mit anderen Worten, Sie können Ihr technisches Risiko geringfügig verringern, aber Ihr finanzielles Risiko durch Offenlegung erhöhen. Natürlich ist jede Situation anders - und die Analyse der Reduzierung des technischen Engagements gegenüber finanziellen Risiken ist nicht trivial. Hier ist eine veranschaulichende Analogie:Einige Banken benötigen trotz des inhärenten Risikos schwache Passwörter , da ihre Verluste durch schwache Passwörter geringer sind als die Endbenutzerkosten für die Unterstützung starker Passwörter.

🔥 Wenn Sie den letzten Absatz gelesen haben und dachten "Ein Typ im Internet namens Brian sagt, ich kann Javascript-Krypto verwenden", verwenden Sie keine Javascript-Krypto.

Für den in der Frage beschriebenen Anwendungsfall erscheint es für Benutzer sinnvoller, ihre lokale Partition oder ihr Ausgangsverzeichnis zu verschlüsseln und ein sicheres Kennwort zu verwenden. Diese Art von Sicherheit ist im Allgemeinen gut getestet, allgemein vertrauenswürdig und allgemein verfügbar.

Brian M. Hunt
quelle
Es gibt zusätzliche Dokumentationen (Zitate) für die allgemeine Haltung der NCC-Gruppe "Keine JavaScript-Krypto verwenden" aus dem Jahr 2011: JavaScript-Kryptographie wird als schädlich angesehen (insbesondere aufgrund des Problems, dass das Tool heruntergeladen wurde, um die Downloads zu überprüfen ... PRNG-Qualität …
Usw.
58

Nun, die Grundvoraussetzung hier ist: Nein, es ist noch nicht sicher.

Grundsätzlich können Sie Krypto nicht in JavaScript ausführen: JavaScript-Krypto wird als schädlich eingestuft .

Das Problem ist, dass Sie den Kryptocode nicht zuverlässig in den Browser übertragen können, und selbst wenn Sie könnten, ist JS nicht dafür ausgelegt, dass Sie ihn sicher ausführen können. Solange Browser nicht über einen kryptografischen Container verfügen (den Encrypted Media Extensions bereitstellen, für DRM-Zwecke jedoch gesammelt werden), ist dies nicht sicher möglich.

Was einen "besseren Weg" betrifft, gibt es derzeit keinen. Ihre einzige Alternative besteht darin, die Daten im Klartext zu speichern und auf das Beste zu hoffen. Oder speichern Sie die Informationen überhaupt nicht. In jedem Fall.

Entweder das, oder wenn Sie brauchen diese Art von Sicherheit, und Sie müssen die lokale Speicherung, erstellen Sie eine benutzerdefinierte Anwendung ...

ircmaxell
quelle
8
Downvoter: Können Sie eine bessere Antwort geben? Mir ist klar, dass dies ein etwas kontroverses Thema ist, bei dem es erhebliche Meinungsverschiedenheiten zwischen Sicherheitsexperten (und auch Nichtfachleuten) gibt. Daher wäre es wert, den alternativen Standpunkt zu teilen. Wie kann ich diese Antwort verbessern, es sei denn, Sie stimmen aus einem anderen Grund ab?
Ircmaxell
9
@ircmaxell nicht ich, aber ich bin mit dieser Antwort nicht einverstanden. "Das Problem ist, dass Sie den Kryptocode nicht zuverlässig in den Browser übertragen können, und selbst wenn Sie könnten, ist JS nicht dafür ausgelegt, dass Sie ihn sicher ausführen können." - Warum? Was ist das inhärente Problem? Sie können die Stanford JavaScript-Verschlüsselungsbibliothek verwenden und darin verschlüsseln / entschlüsseln. Sie können hashen und alles sicher erledigen. Ich sehe das inhärente Problem hier nicht in einer Offline-App in JS, die Standard-Crpyto ausführt, ähnlich wie eine App, die in einer anderen Sprache erstellt wurde.
Benjamin Gruenbaum
11
@BenjaminGruenbaum: Das Problem ist, dass es mehrere Stellen gibt, an denen dieser Kryptocode mit Code von Drittanbietern interagieren müsste. Der springende Punkt dieses Artikels, auf den ich verlinkt habe, ist, dass Sie die Ausführungsumgebung nicht steuern können. Sie installieren also die Stanford Crypto lib. Was passiert dann, wenn ein Browser-Plugin überschreibt, sjcl.encryptum den Schlüssel per E-Mail an den Angreifer zu senden? In JS ist das zu 100% möglich und Sie können nichts tun, um es zu stoppen. Und das ist der zugrunde liegende Punkt. Es gibt keine "Sicherheits" -Mechanismen, die verhindern, dass andere JS böse Dinge mit Ihren Daten tun. Und das ist ein Problem .
Ircmaxell
13
@ircmaxell Wenn Sie mit Hunden schlafen, können Sie nicht erwarten, nicht mit Flöhen aufzuwachen. Wenn der Benutzer ein Malware-Add-On installiert, das genau so ist wie der Benutzer, der einen Virus auf seinem PC installiert, unterscheidet es sich nicht davon. Ihr Java- oder C-Programm kann so sicher wie möglich sein, aber sobald der Angreifer die Möglichkeit hat, Code auszuführen, sind Sie fertig. Das ist bei JS nicht anders. Addons erscheinen nicht nur auf magische Weise im Browser. Darüber hinaus würde es in keiner Weise helfen, die verschlüsselten Informationen zu speichern, wenn der Benutzer über Malware verfügt, da dies nur dazu führen könnte, dass die Daten live entführt werden.
Benjamin Gruenbaum
9
@BenjaminGruenbaum: nicht einverstanden. In einer normalen Anwendung müssen Sie entweder die App selbst kompromittieren (um Speicherorte zu lesen) oder Root-Zugriff auf die Box erhalten (das Betriebssystem gefährden). In jedem Fall müssen Sie etwas Tieferes kompromittieren, als nur normales Verhalten. JS erlaubt dies bei normalem Verhalten. Welches ist das Problem ...
ircmaxell
12

Zur Erforschung dieses Themas habe ich eine Präsentation mit dem Titel "Sichern von TodoMVC mithilfe der Web Cryptography API" ( Video , Code ).

Es verwendet die Web Cryptography API , um die Aufgabenliste zu speichern, die in localStorage durch ein Kennwort verschlüsselt ist, das die Anwendung schützt, und einen vom Kennwort abgeleiteten Schlüssel für die Verschlüsselung verwendet. Wenn Sie das Passwort vergessen oder verlieren, erfolgt keine Wiederherstellung. ( Haftungsausschluss - es war ein POC und nicht für die Produktion bestimmt. )

Wie in den anderen Antworten angegeben, ist dies immer noch anfällig für XSS oder Malware, die auf dem Clientcomputer installiert sind. Alle vertraulichen Daten befinden sich jedoch auch im Speicher, wenn die Daten auf dem Server gespeichert sind und die Anwendung verwendet wird. Ich schlage vor, dass Offline-Support der überzeugende Anwendungsfall sein kann.

Letztendlich schützt die Verschlüsselung von localStorage wahrscheinlich nur die Daten vor Angreifern, die nur Lesezugriff auf das System oder seine Sicherungen haben. Es bietet eine kleine Tiefenverteidigung für die A6-sensible Datenexposition von OWASP Top 10 und ermöglicht Ihnen die Antwort "Sind diese Daten langfristig im Klartext gespeichert?" korrekt.

Kevin Hakanson
quelle
3

Dies ist ein wirklich interessanter Artikel hier. Ich erwäge die Implementierung einer JS-Verschlüsselung, um Sicherheit bei der Verwendung von lokalem Speicher zu bieten. Es ist absolut klar, dass dies nur dann Schutz bietet, wenn das Gerät gestohlen wird (und korrekt implementiert ist). Es bietet keinen Schutz gegen Keylogger usw. Dies ist jedoch kein JS-Problem, da die Keylogger-Bedrohung ein Problem aller Anwendungen ist, unabhängig von ihrer Ausführungsplattform (Browser, nativ). In Bezug auf den Artikel "JavaScript Crypto als schädlich angesehen", auf den in der ersten Antwort verwiesen wird, habe ich eine Kritik; Darin heißt es: "Sie könnten SSL / TLS verwenden, um dieses Problem zu lösen, aber das ist teuer und kompliziert." Ich denke, dies ist eine sehr ehrgeizige Behauptung (und möglicherweise eher voreingenommen). Ja, SSL hat Kosten,

Mein Fazit: Es gibt einen Platz für clientseitigen Verschlüsselungscode. Wie bei allen Anwendungen müssen die Entwickler jedoch die Einschränkungen erkennen und implementieren, wenn dies für ihre Anforderungen geeignet ist, und sicherstellen, dass es Möglichkeiten gibt, die Risiken zu minimieren.

Paul S.
quelle
In der Vergangenheit waren mit den anfänglichen Verbindungsverhandlungen außerordentliche (mechanische, nicht finanzielle) Kosten verbunden. Bis zu dem Punkt, dass Unternehmen dedizierte SSL-Terminierungs-Appliances verwenden würden, die über die Kosten für die Ausstellung und Sicherung von Zertifikaten hinaus finanziell kostspielig werden könnten. Heutzutage wurden viele dieser Probleme behoben, z. B. die Persistenz von Sitzungen mit verlängerter Dauer, um den anfänglichen Handshake bei nachfolgenden Anforderungen zu vermeiden.
Amcgregor
2

Kein Zugriff auf eine Webseite (true), aber leicht zugänglich und über Entwicklungswerkzeuge wie Chrome (ctl-shift-J) leicht zu bearbeiten. Daher ist vor dem Speichern des Werts eine benutzerdefinierte Krypto erforderlich.

Wenn Javascript jedoch entschlüsselt (validiert) werden muss, wird der Entschlüsselungsalgorithmus angezeigt und kann manipuliert werden.

Javascript benötigt einen vollständig sicheren Container und die Fähigkeit, private Variablen und Funktionen, die nur dem js-Interpreter zur Verfügung stehen, ordnungsgemäß zu implementieren. Dies verletzt jedoch die Benutzersicherheit, da Tracking-Daten ungestraft verwendet werden können.

Folglich wird Javascript niemals vollständig sicher sein.

Rockmo
quelle
-29

Nein.

Auf localStorage kann von jeder Webseite aus zugegriffen werden. Wenn Sie über den Schlüssel verfügen, können Sie die gewünschten Daten ändern.

Wenn Sie jedoch einen Weg finden, um die Schlüssel sicher zu verschlüsseln, spielt es keine Rolle, wie Sie die Daten übertragen. Wenn Sie die Daten in einem Abschluss enthalten können, sind die Daten (etwas) sicher.

hellol11
quelle
19
Es ist kein Zugriff auf "irgendeine Webseite". Es ist nur für Seiten in der aktuellen Domain zugänglich.
dtabuenc
@dtabuenc Im Gegenteil, ich habe vor einiger Zeit einen Stift erstellt, der Ihnen jedes einzelne Schlüssel / Wert-Paar in Ihrem localStorage ohne Hacks anzeigt .
hellol11
3
Nee! Es tut uns leid. Der lokale Speicher ist pro Domäne isoliert. Code, der in einer Domäne ausgeführt wird, kann nicht auf Werte zugreifen, die von einer anderen Domäne im lokalen Speicher gespeichert wurden. Zum Beispiel speichert google.com eine Reihe von Dingen im lokalen Speicher. In Ihrem Stiftbeispiel können Sie keinen der Schlüssel von google.com auflisten.
dtabuenc
@dtabuenc hat es getestet, du hast recht.
hellol11