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.

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.

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 ...

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.

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.

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.

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.