Hm... der Unterschied liegt wohl darin, dass der Firefox im angesprochenen Fall die Daten automatisch in ein Formular eingetragen hat und ein Klick dieses dann abschickt. Sind die Felder auf display:none gesetzt, merkt der User nicht, dass er bei einem Klick ein Formular abschickt, dass vom Fx automatisch ausgefüllt wurde. Da halt ich es schon für sinnvoll, wenn der User zu einem bewussten Klick gezwungen ist.
[Erw] Opera Wand (Zauberstab) für Firefox - Secure Login
-
madblueimp -
31. Januar 2007 um 20:03 -
Erledigt
-
-
In dem Bug, den ich kenne, geht es darum, dass ein Formular ausgefüllt wird, dass von einem Phisher per XSS-Lücke der Webseite (Myspace) auf der Seite platziert wurde, aber auf eine andere Domain zeigt. Und da hilft nichts anderes als das Vergleichen der action-Attribute.
-
Ich habe diese Extension aus zwei Gründen geschrieben:
Erstens, weil ich es komfortabler finde, sich per Shortcut (ALT+N) oder einen Toolbar Button einzuloggen, anstatt den Submit Button auf der Seite zu suchen.
Zweitens, weil es eine Sicherheitstechnische Verbesserung darstellt, die Login-Felder nicht automatisch auszufüllen.
Warum ist das automatische Ausfüllen der Login-Felder unsicher?
Es ist deswegen unsicher, weil der Passwort-Manager von Firefox die Login-Daten nicht explizit für eine bestimmte Webseite (z.B. http://example.org/trusted/login.htm) speichert, sondern immer für eine Domain, bzw. Subdomain (example.org).
Das setzt voraus, das allen Webseiten unterhalb dieser Domain das gleiche Vertrauen entgegengebracht werden kann.
Genau das ist aber nicht immer der Fall. Denn manche Websites teilen sich die Domain oder Subdomain und befinden sich nur in unterschiedlichen Unterverzeichnissen.
Falls wir also für die Seite http://example.org/trusted/login.htm Login-Daten hinterlegt haben, und danach auf http://example.org/evil/page.htm surfen, braucht es keine XSS-Lücke, unsere Login-Daten werden automatisch in vorhandene Formular-Felder eingetragen (da wir sie ja für die selbe Domain hinterlegt haben) und können bei aktiviertem JavaScript sogar ohne weiteres zutun automatisch abgeschickt werden.Genau vor diesem automatisiertem Phishing schützt meine Extension, da eine Benutzeraktion nötig ist, um die Login-Daten einzutragen.
Natürlich muss man auch mit SecureLogin darauf achten, das man sich auf der richtigen Seite einloggt, und nicht auf einer Phishing-Seite mit ähnlich klingender URL und gleichem Aussehen.
Seit der Version 0.1.4 kann man mit SecureLogin durch "hovern" über eines der Icons (Statusbar oder Toolbar) auch das Ziel des Logins, die URL des "action"-Attributs des Formulars überprüfen.
Letztlich kann das aber nicht vor direkter Manipulation der Login-Seite schützen. Schafft es ein Angreifer, z.B. durch Cross-Site Scripting eigenen JavaScript-Code einzubetten, kann er z.B. das action-Attribut erst beim Submit des Formulars manipulieren.
Auch zu diesem Szenario habe ich mir beim Entwickeln der Extension Gedanken gemacht. Um solche Manipulationen zu unterbinden, müsste man alle JavaScript-Event-Handler kontrollieren, die direkt mit dem Login-Formular in Zusammenhang stehen.
Das deaktivieren dieser Event-Handler würde aber vielleicht auch zu Komplikationen mit Login-Seiten führen, die selbst JavaScript verwenden, z.B. für die Client-seitige Überprüfung der Eingabedaten.
Es bleibt aber eine Option, die ich vielleicht mal integrieren werde.
Bis dahin hilft es auch einfach, JavaScript selbst für die vertrauenswürdige Seite (zumindest für das Login-Formular) zu deaktivieren, z.B. mit der NoScript-Extension, die ich auch allgemein als Sicherheits-Erweiterung unbedingt empfehlen würde.
Vor client-seitigem XSS kann man sich auch einfach schützen, in dem man Login-Formulare direkt über die URL aufruft, z.B. aus den Lesezeichen.
Als Referenz, die mich auch mit zur SecureLogin-Extension inspiriert hat, hier noch einmal die Heise-Security-Meldung:
Passwort-Manager von Firefox erleichtert Phishern die Arbeit
-
... außerdem reicht nun so ein klick. Kommt darauf an wo man ist.
1. automatisches ausfüllen
2. durch Doppelklick mit Klick auf Username wird ausgefüllt
3. erster Buchstabe eingeben, dann wird ausgefüllt
4. bleibt alles leer, egal wieviel Mal man das Kennwort speichert (passiert oft in Unterforen, die erst durch ein passwort freigegeben werden)Nun alles mit einem klick, braucht man nicht mehr zu überlegen, Buchstabe, oder Doppelklick... Mist, ist ja ne andere Seite, nicht die, die fürs Passwort gespeicherte.
-
Zitat von Dr. Evil
dass von einem Phisher per XSS-Lücke der Webseite (Myspace) auf der Seite platziert wurde, aber auf eine andere Domain zeigt
Afaik wurde in dem Bugeintrag mehrfach drauf hingewiesen, dass es sich nicht um XSS handelt, sondern um das Einschleusen eines HTML-Formulars. Wäre es XSS, sind die Möglichkeiten völlig anders.
Zitat von Dr. EvilUnd da hilft nichts anderes als das Vergleichen der action-Attribute.
In der aktuellen Debatte im Bugzilla-Eintrag kann man die Diskussion darüber gut verfolgen. Der Weisheit letzter Schluss ist es nicht. Aber damit du mich nicht falsch verstehst. Mir geht es darum, dass ein Automatismus an der Stelle einfach nicht sinnvoll ist. Das Eintragen eines Passwortes sollte ein bewusster Vorgang sein. Das wird durch die Erweiterung gewährleistet.
Grundsätzlich sollte die Passwortverwaltung überarbeitet werden. Auch um die angestrebten Änderungen zu reflektieren. Bisher ist der PWM einfach zu wenig informativ und funktionell. Warum dem User nicht mehr Kontrolle geben für welche Seiten das Passwort gespeichert wird? Warum diese Werte nicht anzeigen? Warum nicht editierbar machen? Ich hätte gern mehr Kontrolle darüber, auch in Bezug auf URL und action-Attribut (Möglichkeiten Angaben über reguläre Ausdrücke zu definieren). Natürlich ist das etwas für Power-User, aber ich bin skeptisch ob ein PWM in der bisherigen Form für den Otto-Normal-User geeignet ist. Darüber wurde im Bugeintrag auch schon debattiert. Es ist einfach kaum möglich das Eintragen sensibler Daten für den User zu einer einfachen Funktion zu machen, bei der der User die Hintergründe nicht zu kennen braucht. Mehr Transparenz, auch mit der Konsequenz, dass sich der User etwas Wissen aneignen muss, halte ich in Bezug auf sensible Daten für sinnvoll. Ein erster Schritt in die Richtung stellt für mich diese Erweiterung dar.
-
Hallo zusammen -
ich würde Eure Begeisterung über "SecureLogin" ja gern teilen, allein ich bekomm' die Erweiterung einfach nicht zum Laufen. Hab' inzwischen die Version 0.1.4 installiert, aber jedes gelb umrandete Feld bleibt leer.
Hat jemand 'nen Tip für mich?Danke und Gruß
- Clothilde - -
Schlüsselklicken... und siehe Punkt 2-3, funktionieren auch noch.
@ The Add-ons.Bastler:
Sache se mal junger Mann, könnte se da net noch se ne Feld einbauen, mit dem Weg zu einem Sound? Wisse se, seit dem ich wie in Opera klicken kann, muß ich immer manuell den irc-Sound parallel drücken - "ich bin drin". Des wär ä schee Sach', so als Option und Klangschmankerl zum U-Boot-ping von Meddle des Popup-Fensters.
-
Wunderbar! Ich habe gerade nach so was gesucht. Bei mir funktioniert es sehr gut, ohne irgendwelcher Probleme. Danke sehr!
-
-
Zitat von boardraider
Auch wenn du auf den Schlüssel klickst? Falls ja, dann bitte Beispielseite nennen.Ja gewiß, auch wenn ich auf den Schlüssel klicke.
Z.B. http://www.firefox-browser.de/forum/
oder http://www.firefox-browser.de/forum/login.php
oder http://www.thunderbird-mail.de/forum/index.php
oder http://forum.kaspersky.com/index.php?act=Login&CODE=00- Gruß -
Clothilde -
Zitat
Kann da keine Probleme feststellen.
Hast du noch andere Erweiterungen? Ggf. Konflikt?
Teste es mal mit einem neuen Profil und nur diesem Add-On.
-
@ boardraider
So, jetzt hab' ich es mit 'nem neuen Profil zum Laufen bekommen - hurra!
Soweit ich feststellen konnte lag es nicht an den außerdem installierten Erweiterungen. War wohl irgendein "Urschlamm" aus dem alten Profil der dem SecureLogin im Wege stand.Danke für die Antworten und Gruß
Clothilde -
Zitat
Version 0.2 has been released.
Bugfixes:
- Form elements not of type="text" between user and password field are now ignored in searching the login fields.New features:
- Settings menu
- Context menu on status bar icon to open the settings
- Option to hide the status bar icon
- Option to deactivate JavaScript event handlers on login ** This can prevent XSS (Cross Site Scripting) attacks to steal your login data without having to deactivate JavaScript completely.
http://forums.mozillazine.org/viewtopic.php?p=2736231#2736214 -
S.i.T.: Ein Sound beim Login wäre machbar, ist jetzt auf meiner Prioritäten-Liste aber nicht ganz oben.
-
Freut zu hören!
ZitatEin Sound beim Login wäre machbar, ist jetzt auf meiner Prioritäten-Liste aber nicht ganz oben.
*urks* Wäre sowieso ein Feature, ich gleich wieder abschalten wurde.
-
Zitat
Version 0.3 has been released.
Bugfixes:
- The updateStatus method had been called twice onStateChange - fixedNew features:
- Statusbar icon indicates if JavaScript event handlers are present for logins
- Tooltip (statusbar and toolbar) indicates if JavaScript event handlers are present for logins
- A sound can be played if JavaScript event handlers are present for logins
- Another sound can be played if logins have been found (but no event handlers)Notice:
Sound files are not included. The settings dialog allows to choose them from the local filesystem.
The audio files must be Wave-Audio (*.wav) and should be very short.Important:
JavaScript event handler search is only active if valid logins found.
Only the event handlers associated with the login action are analyzed.
http://forums.mozillazine.org/viewtopic.php?p=2736785#2736785D.h. Sounds können jetzt optional aktiviert werden.
Ich habe es so implementiert, das es mir sinnvoll erscheint, nämlich in dem bei vorhanden, dem Login-Vorgang (z.B. onsubmit) zugeordneten JavaScript Event-Handlern eine Warnung ausgegeben werden kann.Es wäre nicht schlecht, wenn jemand mal verschiedene JavaScript Events aus HTML-Seiten heraus testen würde, um die Zuverlässigkeit der Option "JavaScript Event-Handler vor dem Login deaktivieren" zu überprüfen.
Getestet werden soll der Versuch, die Login-Daten zu stehlen (im Test per alert ausgegeben), die SecureLogin direkt vor dem submit in die Formularfelder einträgt.
Das habe ich zwar die letzten Stunden schon die ganze Zeit getestet, aber vielleicht übersehe ich ja auch irgend etwas... ist auch schon spät/früh. :roll: -
das freut mich zu lesen.
Zitat
S.i.T.: Ein Sound beim Login wäre machbar, ist jetzt auf meiner Prioritäten-Liste aber nicht ganz oben.So als iPunkt, am Schluß
-
Zitat von madblueimp
Nicht mehr erreichbar!?!?
-
Ich hab meinen Webhoster gewechselt.
Die neuen DNS-Einträge haben sich vielleicht noch nicht auf alle Server verbreitet.
Bis dahin kann man auch direkt die neue IP verwenden: -
Zitat von madblueimp
Ich hab meinen Webhoster gewechselt.
Die neuen DNS-Einträge haben sich vielleicht noch nicht auf alle Server verbreitet.
Bis dahin kann man auch direkt die neue IP verwenden:Kannst du deinem neuen Webhoster auch mitteilen, dass das Mime-Format
für die xpi korrekt geliefert wird ?Zur Zeit fragt FX ab, was er damit machen soll bei 1fach-Klick auf "Install Now".
...:AOD:...
-