Wiederherstellungsfunktion von Safari speichert Login-Daten im Klartext
Die Wiederherstellungsfunktion eines Browsers ist für den Nutzer eine richtig praktische Sache. Nach einem Neustart des Browsers lassen sich die zuletzt geöffneten Seiten ohne große Umstände wieder öffnen. Eingeloggt und als ob man nie weg gewesen wäre. An sich kein Problem, doof nur, wenn die Login-Daten unverschlüsselt in Dateien herumliegen, auf die Angreifer praktisch problemlos zugreifen könnten.
Das fanden die Analaysten von Kaspersky nun nämlich heraus. Die Seiten, die beim Beenden des Safari Browsers gespeichert werden, landen in einer einfachen PLIST-Datei. Diese ist zwar in einem versteckten Ordner untergebracht, da ran zu kommen ist allerdings kein Problem. Kommt man also an diese PLIST-Datei und der Nutzer war beim Schließen des Browsers noch in die Dienste eingeloggt, werden die Login-Daten mitgespeichert, um beim erneuten Starten wieder direkt an der gleichen Stelle weiter machen zu können.
Apple wurde über diesen Umstand von Kaspersky informiert, reagierte allerdings noch nicht. Auch ist nicht bekannt, ob es bereits Schadcode gibt, der sich die besagte PLIST-Datei schnappt.
Wird geladen ...
Es gibt doch schon seit Jahren Programme welche ohne Adminrechte die Passwörter von allen Browsern auslesen können?
Bei Chrome hilft da wenigsten das zusätzliche Verschlüsseln mittels Passwort.
Der Unterschied ist wohl, dass man hier die Daten noch nicht mal explizit speichert, sondern Safari es im Hintergrund von alleine macht, damit alles „so easy“ zu nutzen ist 😉
das ist u.a. ein Grund diese „ach so tollen“ Wiederherstellungssachen, ob von Apple oder Google, nicht zu nutzen…
Sascha, in so einen Text gehört „Sicherheitslücke“ ganz groß in die Überschrift. Außerdem ein paar Links auf englische Seiten.
Ach so, diesmal nicht Android? Na dann kann man das auch weniger reißerisch machen.
Nee, erstmal gehören in den Text der Quelle ein paar mehr Details. Worum handelt es sich hier überhaupt? Safari speichert weder Formularfelder noch POST- oder GET-Werte.
Was ebenfalls nicht in der Quelle steht und schon etwas lächerlich ist: der Bug ist seit Safari 6.1 behoben.
Das was Andy sagt
Wie ist der Bug denn behoben worden? Wie sollen solche Daten denn verschlüsselt werden wenn kein Masterpasswort gesetzt ist?
@Jakob
Indem der Schlüsselbund verwendet wird zb- da gibt’s einige denkbare Varianten- sie dürfen halt nur nicht als Klartext irgendwo stehen.. Andere Browser schaffen das ja auch
Bei 10.9 und Safari 7.0 ist die Datei verschlüsselt.
Dennoch ist der Artikel nicht so dolle. Alarmglocke läuten, weniger Informationen als man in einer Minute selber ergoogeln könnte,keine Link zur Originalmeldung. Sogar die Computer Bild würde das besser machen.
Achja hatte vergessen, dass das mac os betrifft. Aber unter windows wäre eine „verschlüsselung“ ohne masterpasswort trotzdem sinnlos…
Desshalb war die Entscheidung von google eigentlich auch richtig alle Passwörter bei Chrome anzuzeigen wenn kein masterpasswort vergeben wurde, aber die Dau’s wollten sich halt lieber sicher fühlen als sicher zu sein…
is das auf dem screenshot fer midnight commander für *nix? der norton commander für mac os bestimmt nicht, oder?