Sind SqlCipher offene Cursor ein Sicherheitsrisiko?

Ich verwende SqlCipher mit Inhaltsanbietern. Gerade jetzt, wenn ich die App sperren möchte, lösche ich einfach das zwischengespeicherte Passwort. Die App kann jedoch weiterhin mit allen offenen Cursorn arbeiten. Dies bedeutet, dass das erneute Öffnen der App den Zugriff auf die sensiblen Daten ermöglicht. Ich behebe dieses Problem auf der Oberfläche, indem ich zu einem Anmeldebildschirm umschalte, wenn die App keine Passwörter hat.Sind SqlCipher offene Cursor ein Sicherheitsrisiko?

Ich bin jedoch besorgt, wenn es Sicherheitsprobleme mit diesen offenen Cursor gibt oder wenn ich nur weiterhin den Zugriff auf die Benutzeroberfläche blockieren sollte und keine Sorge? SqlCipher's Dokumente sagen, dass es verschlüsselte Seiten im laufenden Betrieb liest/schreibt, im Gegensatz zur Entschlüsselung der gesamten DB, dies lässt mich denken, dass offene Cursor immer noch sicher sind.

Das Hauptproblem hier ist, dass jemand ihr Telefon verliert und dann kann eine sachkundige Person diese offenen Cursor verwenden, um sensible Daten zu extrahieren.

Quelle

2012-03-30 user1178479

Ich habe die Details der SQLCipher für Android-Implementierung von Cursorn nicht angeschaut, aber in Android-Cursors halten die gesamten Ergebnismenge im Heap-Raum, und im Falle von SQLCipher würden diese an diesem Punkt entschlüsselt werden.

Da diese Cursors jedoch für Ihren Prozess privat sind, gibt es keinen guten Weg für Sie, mit Hilfe von Linux/Android-Prozess-Isolation, außer über Ihre Benutzeroberfläche. Wenn Ihre Benutzeroberfläche es niemandem ermöglicht, über eine erneute Anmeldung hinauszukommen, sind Sie ziemlich gut geschützt. Der Haken besteht darin, ob Sie sicher sind, dass Ihre Benutzeroberfläche keine unbeabsichtigten Codepfade enthält, die die Anmeldung umgehen würden (z. B. die Liste der letzten Aufgaben) und den Zugriff auf die Daten zulassen.

Quelle

2012-03-30 18:09:22 CommonsWare

In Bezug auf unbeabsichtigte Codepfade. Mein erster Versuch war, eine benutzerdefinierte Aktivitätsklasse zu schreiben, die alle möglichen Einstiegspunkte (onCreate, newIntent usw.) überprüft und dann diese sichere Aktivitätsklasse erweitert. Dies erwies sich in der Theorie als besser als in der Praxis. Im Moment überschreibe ich einfach jeden der oben genannten Einstiegspunkte in jeder Aktivitätsklasse. Leider wirft das meine App mit sich wiederholendem Code aus. Irgendwelche Gedanken, wie man das besser erreichen kann? Ich könnte den Aktivitätsstapel jedes Mal, wenn die App gesperrt ist, beenden und die Überprüfung nur bei der Hauptaktivität durchführen? – user1178479

@ user1178479: "Ich könnte den Aktivitätsstapel jedes Mal beenden, wenn die App gesperrt ist, und die Überprüfung nur bei der Hauptaktivität durchführen?" - Wenn das Sperren der App eine explizite Operation ist, können Sie 'FLAG_ACTIVITY_CLEAR_TOP' und' FLAG_ACTIVITY_SINGLE_TOP' als 'Intent'-Flags verwenden, um alle anderen Aktivitäten zu zerstören, wenn Sie Ihre Sperraktivität über' startActivity() 'aufrufen. – CommonsWare

das ist gut, aber es wäre immer noch möglich, diesen Ansatz zu umgehen, wenn Ihr Manifest Absichtsfilter (wie "action.view") hat, die eine andere Aktivität starten würden, was Ihr Punkt vom ersten Post war. Ich nehme an, der einzige Weg, die Kontrolle wirklich zu zentralisieren, wäre, eine Gatekeeper-Aktivität zu erzeugen, die alle Absichten durchläuft, zusätzlich zum Löschen des Aktivitätsstapels nach dem Sperren. aber das könnte mehr Arbeit sein, als es wert ist, und würde das Manifest praktisch nutzlos machen. – user1178479

Sind SqlCipher offene Cursor ein Sicherheitsrisiko?

Antwort

Verwandte Themen