Frage:
Müssen wir uns von Webanwendungen abmelden?
Angelo.Hannes
2013-10-14 12:03:12 UTC
view on stackexchange narkive permalink

Eine schnelle Google-Suche zeigt nicht, ob es wichtig ist, sich von Webanwendungen abzumelden (Online-Banking, Amazon, Facebook usw.) oder ob ich sicher bin, nur den Tab oder den Browser zu schließen. Ich bin mir sicher, dass ich in einer Fernsehsendung gehört habe, dass es am besten ist, sich abzumelden ...

Welchen möglichen Bedrohungen bin ich ausgesetzt, wenn ich mich nicht ordnungsgemäß abmelde?

Betrachten Sie das Schließen eines Tabs als das Gleiche wie das Nicht-Schließen eines Tabs.
@domen das ist nicht IMMER wahr. Siehe z. meine Antwort.
In Lettland übernimmt die SwedBank Internetbanking auch die IP-Adresse. Ich denke, dass andere Banken das auch tun. Beispiel aus dem wirklichen Leben: Ich habe zu Hause zwei Internetverbindungen eingerichtet (packbasierter Lastausgleich) und kann das Internetbanking überhaupt nicht nutzen, da ich nach 2 oder 3 Klicks abgemeldet werde. Ich habe mich mit einer IP authentifiziert und dann eine weitere Anfrage mit der zweiten IP gestellt. In diesem Fall funktioniert das Stehlen von Cookies nicht.
Es spielt keine Rolle, ob Sie eine Rails-Anwendung verwenden, da "[Die Abmeldung in Ruby on Rails-Webanwendungen ist standardmäßig unterbrochen] (http://maverickblogging.com/logout-is-broken-by-default-ruby-on-rails) -web-Anwendungen /) "... SCNR
@thatguyfromoverthere danke für den Fund, den habe ich verpasst! Beachten Sie, dass diese Art von Fehler in maßgeschneiderten Anwendungen häufig genug ist, wie ich in einem Kommentar unten erwähnt habe. Es handelt sich nicht nur um Rails.
@AviD Ich habe Ihre Antwort gelesen. Was genau meinst du?
@domen Es gibt Aspekte, die vom Schließen der Registerkarte betroffen sind. Z.B. für Basic Auth, wenn Sie es mit -NoFrameMerging oder Private Browsing geöffnet haben.
Als Randnotiz: Es ist interessant zu überprüfen, ob Ihre kritische Anwendung eine erneute Authentifizierung erzwingt, idealerweise auf andere Weise (= wenn Sie sich mit Login / Passwort anmelden, erneut authentifizieren / mit einer SMS bestätigen), bevor Sie a ausführen kritischer Betrieb (wie eine Überweisung für eine Bank). In einer Bankumgebung ist es normalerweise sehr schlecht, wenn jemand Ihr Konto überprüft. Es ist katastrophal, wenn es jemandem gelingt, eine Transaktion durchzuführen (Übertragung)
Ich weiß, dass es bereits viele Antworten gibt, aber es gibt einen Hacker-Atk, der Ihre Cookies stiehlt, und wenn Sie sich nicht abmelden, können sie immer noch wie Sie surfen
@jcho360 Dies wurde in mehreren Antworten auf verschiedene Weise erwähnt. Das hat verschiedene Aspekte, es ist nicht so einfach.
Beachten Sie, dass diese Frage in [LifeHacker] (http://lifehacker.com/do-i-really-need-to-log-out-of-webapps-1482782887) gestellt wurde. Anscheinend ist dies ein häufiges Problem ...
Acht antworten:
AviD
2013-10-14 22:11:07 UTC
view on stackexchange narkive permalink

Dies ist keine triviale, vereinfachende Frage. Es gibt verschiedene Aspekte, die Sie berücksichtigen müssen, und verschiedene Mechanismen und Gegenmaßnahmen, die für verschiedene Bedrohungen in verschiedenen Szenarien gelten, die von mehreren verschiedenen Clients betroffen sind. Lassen Sie uns diese einzeln untersuchen. (Am Ende wird eine TL; DR angezeigt ...)

  • Wenn Sie einen öffentlichen Computer verwenden: LOG OUT.
    Alle Dienste, bei denen Sie ein Konto führen, sollten nicht auf einem öffentlich zugänglichen Computer angemeldet bleiben.

  • Wenn Sie einen trivialen, unempfindlichen Dienst verwenden: Bleiben Sie angemeldet.
    Dies gilt nur für wegwerfbare, temporäre Konten, z Was das Internetradio betrifft, bei dem das Verschenken des Zugangs nichts anderes als ein Ärgernis ist.

  • Wenn Sie öffentliches WLAN verwenden: ABMELDEN.
    Da das Netzwerk von Natur aus nicht vertrauenswürdig ist, gibt es eine große offensichtliche BEDROHUNG: Diebstahl von Sitzungscookies. Möglicherweise wurde Ihre Sitzung entführt, und jemand - entweder eine andere Person im Netzwerk oder der Hotspot selbst - hat Ihr Sitzungscookie gestohlen. Wenn dies der Fall wäre, würden Sie es natürlich nicht wissen, aber dann können Sie sich möglicherweise auch nicht wirklich abmelden (wenn es sich um ein böswilliges Netzwerk oder MITM handelt, haben sie die Kontrolle über Ihre gesamte Verbindung - sie können einfach Ihre Verbindung trennen Abmeldeanforderung).

    Der Diebstahl nur Ihres Sitzungscookies durch Dritte ist jedoch eine gültige Bedrohung (z. B. FireSheep), und die explizite Abmeldung verhindert die unbegrenzte Verwendung. (Grundsätzlich ist der Schaden möglicherweise bereits angerichtet worden, aber dies verhindert, dass er fortgesetzt wird.)

    Noch besser ist es, sich in ein vertrauenswürdiges Netzwerk zu begeben und sich explizit wieder abzumelden, nur für den Fall Das MITM hat Ihre Abmeldung blockiert. Besser noch ist es, Ihr Passwort auf der vertrauenswürdigen Site zu ändern ... Am besten greifen Sie jedoch niemals von einem nicht vertrauenswürdigen Netzwerk aus auf eine nicht triviale, vertrauliche Site zu.

  • Wenn Sie Ganztagesanwendungen verwenden: BLEIBEN SIE ANGEMELDET.
    Für Dienste, die Sie den ganzen Tag nutzen und auf die Sie schnell und einfach zugreifen möchten, z. Facebook, E-Mail usw. - WENN dies Ihr eigener privater (oder geschäftlicher) Computer in einem vertrauenswürdigen Netzwerk ist, ist es ein sinnvoller Kompromiss, Ihren Browser langfristig angemeldet zu lassen.

    GEFAHR : Böswilliger Zuschauer

    Sperren Sie Ihren Computer jedes Mal, wenn Sie weggehen, selbst um eine Tasse Kaffee zu bekommen. Oder schließen Sie Ihr Büro ab, wenn Sie eine physische Tür haben, durch die niemand sonst hindurch kann. (Oder haben Sie ein Home Office, wheee!) Melden Sie sich regelmäßig ab und wieder an. Überwachen Sie alle von Ihnen verfassten Beiträge.

    BEDROHUNG: Andere Websites können registrieren, dass Sie angemeldet sind (zB um dir das wichtige "Gefällt mir" -Symbol von Facebook zu zeigen). Dies ist Teil des geltenden Kompromisses, während es weitere Implikationen gibt, die für diese Antwort nicht relevant sind.

  • Wenn Sie alle Anwendungen verwenden, die die HTTP-Basisauthentifizierung verwenden (z. B. viele Router): MELDEN SIE SICH AUS UND SCHLIESSEN SIE ALLE BROWSER-FENSTER. Hier wird es interessant, und dies gilt auch für den nächsten Abschnitt.

    Wenn Sie sich mit Basic AuthN bei einer Webanwendung anmelden, speichert der Browser Ihr Kennwort zwischen und sendet es bei jeder Anforderung. Der BasicAuth-Mechanismus des Browsers hat kein Sitzungskonzept. Selbst wenn Sie sich wiederholt abmelden, hat die Webanwendung weder auf der Server- noch auf der Clientseite eine Möglichkeit, die Sitzung zu "beenden". Die einzige Möglichkeit, diese zwischengespeicherten Anmeldeinformationen zu löschen, besteht darin, den Browserprozess abzubrechen.

    JEDOCH . Ihre Wahl des Browsers ist für dieses Konzept des "Browserprozesses" von Bedeutung. Zum Beispiel:

  • Firefox : Immer ein einzelner Prozess, egal wie viele Registerkarten und Fenster Sie öffnen.

  • Chrome : Jede Registerkarte ist ein separater Prozess. Es gibt jedoch einen anderen "globalen" übergeordneten Prozess. Alle Registerkartenprozesse sind untergeordnete Prozesse dieses Prozesses (im Windows-Sprachgebrauch als "Jobprozess" bezeichnet) und sie teilen sich den Prozessspeicher über den übergeordneten Prozess . Dies gilt auch, wenn Sie ein neues Fenster öffnen. Während die umfangreichen untergeordneten Prozesse von Chrome mit gemeinsam genutzten übergeordneten Elementen die Registerkarten besonders lebendig und robust machen, besteht der Nachteil darin, dass der Prozessstatus gemeinsam genutzt wird. Mit anderen Worten, die einzige Möglichkeit, zwischengespeicherte BasicAuth-Anmeldeinformationen aus Chrome zu entfernen, besteht darin, alle Chrome-Fenster zu schließen, jedes letzte. Das Schließen der Registerkarte allein hilft nicht.

  • IE : Das Registerkarten- / Prozessmodell ist mit einer Ausnahme identisch (oder ähnlich) wie Chrome. Standardmäßig öffnet der IE auch alle Registerkarten in einem untergeordneten Element des übergeordneten Prozesses. (Tatsächlich ist dies nicht 100% genau - einige Registerkarten teilen einen untergeordneten Prozess mit anderen Registerkarten - aber dies spielt in der Realität keine Rolle). Wenn Sie jedoch " -NoFrameMerging " zur IE-Befehlszeile hinzufügen, wird ein vollständig neuer übergeordneter IE-Prozess erstellt. Der Unterschied besteht darin, dass Sie z. Erstellen Sie ein neues übergeordnetes Fenster, um sich bei Ihrem Router anzumelden, und schließen Sie dann nur dieses Fenster, wenn Sie fertig sind. Dadurch wird Ihr BasicAuth-Cache geleert, ohne dass andere geöffnete IE-Fenster berührt werden. (Randnotiz: Dies ist auch mit Chrome möglich! Es ist jedoch viel aufwändiger und erfordert, dass Sie ein anderes Browserprofil auf Ihrem Computer erstellen.)

  • Wenn Sie sensible Anwendungen verwenden, z Banking-Apps - IMMER AUSSCHLIESSLICH ABMELDEN UND ALLE BROWSER-FENSTER SCHLIESSEN. Dieser Teil ist etwas komplizierter, aber viele der Abhängigkeiten wurden bereits oben behandelt.

    GEFAHR: Böswilliger Zuschauer Das Sperren Ihres Computers wie oben wäre sinnvoll, es besteht jedoch keine Notwendigkeit für einen Kompromiss von zuvor. Melden Sie sich einfach ab.

    Sitzungszeitlimit: Darüber hinaus sollten die meisten vertraulichen (z. B. Bank-) Apps eine Form des automatischen Leerlaufzeitlimits implementieren. Wenn Sie also für den Nachmittag ausgehen, wird Ihre Sitzung irgendwann automatisch beendet. Dies hilft möglicherweise nicht bei dieser Bedrohung, da der böswillige Zuschauer möglicherweise einfach auf Ihren Computer springt, wenn Sie 4 1/2 Minuten aussteigen, um Ihren Kaffee nachzufüllen.

    GEFAHR: Diebstahl von Sitzungscookies

    Hoffentlich verhindern sensible Apps dies aktiv, z. HTTPS, IDS, Geo- / Betrugserkennung usw. Trotzdem ist es immer noch sinnvoll, dieses "Zeitfenster" zu schließen, nur für den Fall - Tiefenverteidigung und all das.

    Sitzungszeitlimit: As Zuvor sollten die meisten sensiblen (z. B. Bank-) Apps eine automatische Zeitüberschreitung im Leerlauf implementieren und dabei helfen, diese Bedrohung zu minimieren. Allerdings , selbst wenn Sie wissen, dass diese App Leerlaufzeitlimits korrekt implementiert, gibt es für den Angreifer immer noch ein Zeitfenster. In einer relativ sicheren App ist dies jedoch keine große Bedrohung.

    GEFAHR: Cross Site Request Forgery (CSRF)

    Dies ist derjenige, über den Sie sich Sorgen machen müssen.

    Angenommen, Sie sind bei Ihrer Bank angemeldet. Im selben Fenster, auf einer anderen Registerkarte, durchsuchen Sie eine zweifelhafte Website. Beim Anzeigen dieser Website werden möglicherweise verschiedene bekannte Bank-Websites heimlich getestet, um festzustellen, ob Sie zufällig bei einer dieser Websites angemeldet sind. Wenn dies der Fall ist, wird der CSRF-Angriff aktiviert (nicht alle Bankseiten sind dafür anfällig, viele jedoch noch). CSRF'd!

    Okay. Angenommen, Sie sind schlauer als dieser andere Typ und durchsuchen verdächtige Websites nicht, wenn Ihre Bankenseite geöffnet ist. Nachdem Sie auf Ihrer Bank fertig sind, schließen Sie die Registerkarte vorsichtig. Erst dann öffnen Sie einen neuen Tab, um zur zwielichtigen Site zu navigieren. Das Problem ist, dass Sie immer noch angemeldet sind und dies für eine Weile tun wird (normalerweise etwa 30 Minuten, aber es können nur 10 oder bis zu einer Stunde sein ...). CSRF'd! .

    (Beachten Sie, dass das Sitzungszeitlimit hier hilfreich ist, indem das Zeitfenster verkürzt wird. Es besteht jedoch weiterhin die Möglichkeit, dass dies innerhalb des Fensters geschieht.)

    Hmm. Nun, ich weiß, öffnen wir ein neues Browserfenster! Verwenden Sie dies für die Bankarbeit, schließen Sie dann erneut die Registerkarte und öffnen Sie erneut eine neue für die Malware-Websites, mit denen ich gerne spiele. Hoppla, lesen Sie den obigen Abschnitt über die Standardauthentifizierung - Ihre Wahl des Browsers ist wichtig.

    Es sei denn, Sie verwenden "inkognito / privates Surfen" oder das Flag " -NoFrameMerging " für IE, Sie befinden sich immer noch in derselben Prozessfamilie , und diese noch offene Sitzung wird von allen Fenstern gemeinsam genutzt, zumindest bis der Server das Leerlaufzeitlimit erreicht. Vorausgesetzt, es wurde noch nicht kooptiert. CSRF'd!

    Okay, noch eine, nur noch eine. Ich habe diesen überlangen Beitrag irgendwo gelesen, wie ich mich immer von meinen sensiblen Apps abmelden muss - also mache ich genau das, bevor ich zu meinen kriminellen Websites gehe. Leider hat die Anwendung "vergessen", sich ordnungsgemäß abzumelden. Sie leitet mich nur aus der Anwendung heraus (oder löscht mein Cookie oder ...), anstatt es auf dem Server ungültig zu machen ... CSRF'd!

    • Also, TL; DR?

    • Wenn Sie sich für Ihr Konto auf dieser Website interessieren: LOG OUT.
    • Wenn Sie sich für Ihr Konto interessieren und es die Basisauthentifizierung verwendet: Melden Sie sich ab und schließen Sie alle Browser-Fenster und -Fenster.
    • Wenn Sie sich nicht für Ihr Konto interessieren - es spielt keine Rolle, was Sie tun, hören Sie auf zu fragen :-).

    P.S. Ich habe Dinge wie Flash-Cookies, Nicht-http-Sitzungen und integrierte Windows-Authentifizierung nicht behandelt. Genug ist genug. sub>

    Gutes Zeug! Eine Sache, die Sie beachten sollten, ist, dass bei der Minderung des Diebstahls von Cookies in Ihrer Sitzung das Aufrufen eines vertrauenswürdigen Computers und das An- und Abmelden davon ausgeht, dass die App. Es wird nur eine einzige gültige Sitzung pro Benutzer zugelassen, und durch das Einrichten der Sitzung wird die vorherige Sitzung ungültig. Leider ist dies bei vielen Apps nicht der Fall (nach meiner Erfahrung ist die gleichzeitige Anmeldung die Mehrheit).
    @RoryMcCune das stimmt! Ich dachte tatsächlich darüber nach, einen Laptop von offenem WLAN in ein vertrauenswürdiges Netzwerk zu verlagern, in dem die Sitzung gleich bleiben würde (eigentlich nicht unbedingt ...). Sie haben jedoch Recht mit nicht vertrauenswürdigen Computern.
    Ich habe auch festgestellt, dass ich nicht einmal erwähnt habe, dass das Abmelden manchmal auch nicht funktioniert ... entweder indem ich es nicht am Server beendet habe, nur das Client-Cookie abgebrochen habe oder andere dumme Fehler wie diesen. Meine implizite Annahme bei all dem ist, dass * Abmelden funktioniert *, wenn Sie es verwenden - diese Annahme gilt nicht immer.
    Um einen wichtigen Punkt der Antwort von AviD herauszuarbeiten: Wenn Sie sich * wirklich * für das Konto interessieren: Beenden Sie alle Browserprozesse, einschließlich aller Plugin-Spawns (eingebettete PDF-, Musik-Player- und Applet-Popups); dann nur auf die Website des Kontos zugreifen; Beenden Sie dann alles erneut, bevor Sie die normalen Surfgewohnheiten neu starten. Stellen Sie im Wesentlichen keine Parallelität beim Zugriff auf kritische Konten sicher, da Browser "Web-Betriebssysteme" sind, die zu mehr Parallelität und Freigabe tendieren, nicht weniger.
    Nebenbei bemerkt, im Zusammenhang mit AviDs zweitem TL; DR-Aufzählungspunkt: Wenn Sie das WebDeveloper-Plugin für Firefox verwenden, Verschiedenes | Private Daten löschen | HTTP-Authentifizierung löschen. Dadurch müssen Sie nicht alle Registerkarten und Fenster schließen.
    Wenn meine Sitzung nicht sicher ist, nachdem ich Tab / Browser geschlossen habe, ist sie nicht sicher, während ich sie verwende, oder? Und damit auch nicht die Webapp für sich?
    Es ist zu beachten, dass Chrome und einige andere Browser über ein "Inkognito-Fenster" verfügen, das separate Anmeldeinformationen und einen Cookie-Cache enthält. Wenn Sie ein Inkognito-Fenster öffnen möchten, um sich auf einer solchen Site anzumelden, müssen Sie danach keine weiteren Fenster mehr schließen.
    Nicht erwähnt (zumindest nicht explizit) ist die Funktion "Erinnere dich an mich", die so viele Websites verwenden. Selbst nach dem Schließen des Browsers und dem Herunterfahren des Computers werden Sie bei "Ihrem" nächsten Besuch auf der Website automatisch angemeldet. Normalerweise stoppt das Abmelden auch die Funktion "Erinnere dich an mich". Dies ist also ein weiterer zusätzlicher Punkt für die Protokollierung aus sensiblen Websites.
    @JanHudec Danke, ich habe mich nur gefragt. Normalerweise surfe ich mit Chrome mit vielen offenen Registerkarten und verwende Safari (unter OSX), um meine sensiblen Aufgaben zu erledigen. Ein Inkognito-Fenster wäre eine gute Alternative.
    @LateralFractal Sehr wahr, und in Bezug auf Plugins, die ich in der Fußnote erwähnt habe, Dinge wie Flash (was am häufigsten vorkommt, nicht nur als vorhanden, sondern mit relevanten Fehlern). Vielen Dank für die anderen Beispiele für Plugins.
    @DarrenCook danke dafür! Ich suche immer nach dieser Option, vergesse immer wieder, dass es nur mit dem WebDeveloper-Plugin zu tun hat ... aber es würde dem kleinen Segment helfen, das das verwendet :-)
    @Angelo.Hannes "sicher" ist ein relativer Begriff. Wenn Sie die Sitzung in einem gemeinsam genutzten Prozess geöffnet haben (d. H. Kein privates Surfen oder NoFrameMerging im Internet Explorer), ist dies nicht unbedingt * unsicher *, es bestehen jedoch bestimmte Risiken. Z.B. Wenn ein CSRF-Fehler vorliegt, ist er anfällig für andere Tabs, die gleichzeitig angreifen usw. Wenn ein Angreifer Ihr Sitzungscookie gestohlen hat, besteht das Risiko, dass Sie keine Tabs verwenden oder nicht, aber es geht nur darum, das Angriffsfenster zu schließen (Also ja - Sie sind nicht unsicherer, nachdem Sie sich nicht abgemeldet haben, als wenn Sie angemeldet sind). Das Problem ist, dass es möglicherweise KEINE Zeitüberschreitung gibt ...
    @JanHudec richtig, das habe ich nur beiläufig erwähnt.
    @CarlosCampderrós ausgezeichneter Punkt! Ich würde annehmen, dass Sie, wenn Sie sich abmelden, nicht an "Erinnern Sie sich an mich" interessiert sind, aber diese Annahme könnte falsch sein. Außerdem ist die Funktion "Erinnere dich an mich" sehr oft sehr unsicher.
    * BEDROHUNG: Böswilliger Zuschauer * - Die meisten böswilligen Zuschauer, die versuchen, meinen Computer zu "entführen", würden aufgrund der Verwirrung von [Dvorak] (http://en.wikipedia.org/wiki/Dvorak_simplified_keyboard) mindestens einige Zeit verlieren ;-)
    @gerrit hehe, ja, aber das ist Sicherheit durch Dunkelheit - und es würde Ihnen wahrscheinlich nur ein paar Minuten kosten. Schließlich werden sie die Tastatur an der Schnur herausreißen, die verstümmelten Teile durch den Raum werfen und ihre eigene Tastatur anschließen.
    @AviD Richtig, es wird einen fokussierten und engagierten Angreifer nicht aufhalten, und ich betrachte es nicht als ernsthaften Schutz. Aber wenn ich buchstäblich nur Tee oder Kaffee trinke, kann eine Minute gerade genug sein, um einen Unterschied zu machen.
    Gilt dieser Rat weiterhin für [Drücken der Zurück-Taste / Verlauf] (http://security.stackexchange.com/q/8404/396), um sich erneut für ein SAML / Verbund-Cookie zu authentifizieren? Es wäre interessant, die Szenarien zu sehen, die sich auf die verschiedenen Caching-Anweisungen auswirken. Sie sind wahrscheinlich im (alten?) Browser-Sicherheitshandbuch von Google dokumentiert
    Adi
    2013-10-14 12:59:36 UTC
    view on stackexchange narkive permalink

    Wenn Sie sich bei einem Webdienst anmelden , wird in Ihrem Browser ein Cookie eingefügt. Dieses Cookie hat einen eindeutigen ID-Wert, der Sie identifiziert, während Sie den Webdienst verwenden, und möglicherweise, wenn Sie später wiederkommen. Wenn diese Kennung irgendwie * gestohlen wurde, könnte die Person, die sie besitzt, Ihr Konto möglicherweise so verwenden, als ob Sie es wären.

    Abmelden macht diese Kennung normalerweise ungültig sowohl Sie als auch der Gegner. Keiner von Ihnen kann die Kennung verwenden, um dem Webdienst " Hallo, ich bin Angelo Hannes " mitzuteilen. Das hat den unglücklichen Nebeneffekt, dass Sie gezwungen werden, Ihren Benutzernamen und Ihr Passwort erneut einzugeben, um sich anzumelden.

    "Also, was soll ich dann tun?", Fragen Sie. Es hängt davon ab. Einige vertrauliche Webdienste (Banken, Regierungswebsites, Versicherungsunternehmen usw.) haben eine kurze Sitzungszeit, d. H. Sie machen die Kennung nach 10 bis 15 Minuten Nichtbenutzung des Dienstes ungültig. Andere vertrauliche Webdienste (E-Mail-Posteingang, der im Grunde fast alle Ihre anderen Konten kontrolliert) machen die Sitzung nicht so oft ungültig, wenden jedoch IP-Adressbeschränkungen an (wenn Sie dieselbe Sitzung von einer anderen IP-Adresse aus verwenden, ist die Sitzung ungültig gemacht).

    TL; DR

    • Öffentlicher Computer, extra paranoid, Sie denken, Ihre Sitzung wurde kompromittiert, oder Sie interessieren sich wirklich für diesen Dienst? Logout

    • Privater Computer, Sie denken, Ihre Sitzung ist sicher, und Sie interessieren sich wirklich nicht für diesen Service? Es ist in Ordnung, angemeldet zu bleiben .

    * Ihre Sitzung kann aufgrund bekannter Probleme im Dienst gestohlen werden (z. B. ohne HTTPS) Beispiel) oder einige Zero-Day-Schwachstellen wie ein neu entdeckter XSS-Angriff im Dienst, eine neue Schwachstelle in Ihrem Browser, die Cookie-Informationen preisgibt, oder eine auf dem von Ihnen verwendeten Computer installierte Malware, die Sitzungsinformationen stiehlt falls es bereits Ihren Benutzernamen und Ihr Passwort gestohlen hätte).

    Die Bedrohungen sind also dieselben, während ich angemeldet und abgemeldet bin, verkürzt sich nur der Zeitrahmen?
    Ich möchte hinzufügen, dass XSS zur Durchführung von Anforderungsfälschungen verwendet werden kann. In diesem Fall ist das Zeitlimit für das Cookie irrelevant.
    Das heißt, wenn mein Laptop gestohlen wird, sollten die Anmeldeinformationen automatisch ungültig werden, da sich die IP ändert.
    @ ŁukaszL. Einige Dienste haben Zeitüberschreitungen, andere Dienste nicht. Einige Dienste haben IP-Einschränkungen, andere nicht.
    Wenn Sie sich tatsächlich für den Dienst interessieren (oder eine Beeinträchtigung des Dienstes zu Angriffen führen kann, die die Dienste beeinträchtigen, die Sie interessieren - z. B. verwenden Sie Ihr E-Mail-Konto, um über ein Zurücksetzen des Kennworts auf Ihr Bankkonto zu gelangen), sollten Sie diese niemals verwenden Der Dienst auf einem öffentlichen nicht vertrauenswürdigen Computer oder auf öffentlichem WLAN (Technisch gesehen ist öffentliches WLAN in Ordnung, wenn sein https für die gesamte Verbindung und weder Ihr Computer noch die Zertifizierungsstelle kompromittiert wurden).
    @drjimbob Wenn USB-Computer wie [Cotton Candy] (http://www.fxitech.com/cotton-candy/what-is-it/) keine Vaporware sind, können Sie auf diese Weise sicher einen nicht vertrauenswürdigen Host-Computer verwenden.
    @LateralFractal - [Hardware-Keylogger] (http://en.wikipedia.org/wiki/Hardware_keylogger). (Sicher, mit der 2-Faktor-Authentifizierung könnten Sie in dieser Situation möglicherweise sicher sein - wenn Ihre gespeicherten Passwörter in den Händen eines Gegners völlig unbrauchbar sind - aber warum sollten Sie sich auch in diesem Fall nicht von Ihrem zweiten Faktor-Gerät aus anmelden?)
    @drjimbob Es gibt ein gewisses Maß an Vertrauen. Wenn also auch die Hardware nicht vertrauenswürdig ist, sind Sie natürlich auf den PC beschränkt, den Sie mitbringen können. Laptops sind jedoch ziemlich groß und Mobiltelefone sind Funkfeuer, sodass ein Computer-Stick von der Größe eines KitKat verlockend ist. Der Zweck von Headless-Computern besteht darin, eine größere Auswahl an geschützten Inhalten als der 256-Bit-Startwert auf einem OTP-Dongle bereitzustellen und gleichzeitig Host-Ressourcen auszuleihen. Ich bin zwar kein Fan von Vaporware - je nachdem, wie es angeschlossen ist, sollten die einzigen Host-Ressourcen ein HDCP-HDMI-Monitor und sein Netzteil sein.
    Oder anders ausgedrückt: * Das Vollkommene ist der Feind des Guten. *
    @LateralFractal - Es wird keine Tastatur verwendet, die möglicherweise nicht Ihre eigene ist? Seit wir in das Zeitalter der mobilen Geräte im Taschenformat eingetreten sind, kann ich mich nicht erinnern, jemals öffentliche / nicht vertrauenswürdige Computer verwenden zu müssen, um beispielsweise meine E-Mails (oder ein schlechteres Bankkonto) zu überprüfen oder mich bei einem Server anzumelden. Und ich bin nicht einmal besonders paranoid.
    @drjimbob In der Praxis wäre die beste Lösung ein Telefon mit der Fähigkeit, gegebenenfalls andere Ressourcen (größerer Monitor, Tastatur, festes Ethernet usw.) zu kooptieren. Derzeit sind Consumer-Handys ([post-Blackberry] (http://goo.gl/ybm7Fl)) * viel * weniger sicher als jeder Desktop - auch ohne Headless. Aber ich fürchte, wir sind vom Thema abgewichen. Wir könnten Chat für die weitere Ausarbeitung verwenden.
    Rohan Durve
    2013-10-14 18:03:47 UTC
    view on stackexchange narkive permalink

    Ich werde versuchen, eine Antwort auf diese Frage in umgekehrter Weise wie oben bereits beschrieben zu geben.

    Welche Risiken sind mit inaktiven Sitzungen in Webanwendungen verbunden?

    • Diebstahl von Sitzungscookies über XSS (wenn die Sitzung nicht an die IP gebunden ist)
    • Fälschung von Cross Site Request (im Leerlauf aber noch authentifizierte Sitzung).
    • Man In The Middle Attacks (mit einem Sniffed-Sitzungscookie mit SSLStrip oder aufgrund der Offenlegung gemischter HTTPS-Informationen)
    • Terminal öffnen (Sie haben eine Mittagspause mit PayPal neben < eingelegt. Geben Sie hier den Namen eines zufälligen Cyberkriminellen ein> und sind zurückgekommen, um Ihr Konto leer zu sehen, weil Sie sich nicht abgemeldet haben.)

    Zeitlimit Wie bereits erwähnt, weisen bestimmte sicherheitskritische Anwendungen wie Bankwebsites niedrige Zeitlimitwerte von im Allgemeinen fünf bis zehn Minuten auf. Diese Anwendungen verfügen jedoch im Allgemeinen auch über zufällige Sequenzierungs-CSRF-Präventionstoken und IPs, die an Sitzungen gebunden sind. Selbst wenn Ihr Cookie kompromittiert ist, kann ein Angreifer aus der Ferne nichts damit anfangen, wenn die Sicherheit ordnungsgemäß implementiert wurde.

    Andere Websites wie FaceBook setzen im Allgemeinen keine Zeitüberschreitungen ein, um den Zugriff oder die Benutzerfreundlichkeit zu verbessern . Sie unterstützen jedoch die Anmeldemeldung und die IP-Bindung an das Cookie. Anwendungen wie Google Mail oder DropBox unterstützen die zweistufige SMS-Authentifizierung, um die Sicherheit weiter zu verbessern und Sitzungsdiebstahl unbrauchbar zu machen, wenn sie von einem neuen nicht vertrauenswürdigen PC stammen.

    Daher wäre die einzige Sorge, die ich hätte Lassen Sie Sitzungen offen auf:

    • Öffentliche Terminals (wo Sie sowieso privates Surfen verwenden sollten. Strg + Umschalt + P auf FF)
    • Websites mit schlechter Sicherheit (Wo der Benutzer dafür verantwortlich ist, die Geheimhaltung seiner Cookies vor den bösen Cookie-Monstern da draußen zu bewahren).
    Ein interessanter Angriffsvektor wäre zu sehen, ob ein Mann im mittleren Sniffer in Ihrem NAT-LAN die Verschlüsselung einer Sitzung unterbrechen, ein Cookie-Token-Paar erhalten, eine böswillige Post-Anfrage fälschen und sie mit dem gekapselten Cookie-Token und Formular verschlüsseln könnte Daten und senden Sie es über Ihre öffentliche IP.
    user31950
    2013-10-14 12:22:41 UTC
    view on stackexchange narkive permalink

    Eine der größten Bedrohungen für das Nicht-Abmelden ist die Verwendung eines öffentlichen Computers. Abhängig von der Browserkonfiguration wird eine Sitzung möglicherweise nicht beendet, wenn Sie den Browser schließen. Wenn der Benutzer vergisst, seinen Betriebssystembenutzer abzumelden (oder dies möglicherweise nicht einmal kann), kann jemand anderes auf seine Webanwendung zugreifen. Dies ist natürlich kein sehr wahrscheinlicher Fall. Webapps sind jedoch häufig für eine große Benutzergruppe zugänglich, und einige Benutzer verwenden möglicherweise öffentliche Computer (Universitäten, Schulen, Bibliotheken).

    Obwohl ich nur meine privaten Geräte im Auge hatte, ist es sinnvoll, öffentlich zugängliche Geräte zu erwähnen. Gleiches gilt für unbeaufsichtigte oder verlorene / gestohlene Geräte.
    Lie Ryan
    2013-10-14 12:23:54 UTC
    view on stackexchange narkive permalink

    Da eine Sitzung eine Zeitüberschreitung aufweist, ist es nur eine kurze Zeit, in der ich angemeldet bin, nachdem ich die Webanwendung verwendet habe.

    Das muss nicht unbedingt stimmen. Abhängig davon, wie die Site ihre Sitzungsverwaltung implementiert, können sie ein beliebig langes Zeitlimit verwenden und sogar Sitzungen verwenden, die den Neustart des Browsers / Betriebssystems überleben.

    Letztendlich hängt es von der Webanwendung ab, ob Sie sich explizit abmelden sollten oder nicht . Bank-Sites implementieren im Allgemeinen eine sehr kurze Zeitüberschreitung, Social-Networking-Sites implementieren im Wesentlichen eine permanente Anmeldung, insbesondere wenn sie auch Identitätsanbieter (OpenID usw.) sind.

    Das Stehlen eines Sitzungscookies ist normalerweise nicht einfach, aber möglich und möglich Das explizite Abmelden verhindert, dass Sie sich im Allgemeinen explizit für Websites mit hohem Wert abmelden sollten.

    Könnten Sie bitte näher darauf eingehen, wie Sie einen Sitzungscookie stehlen? Ist dies generell möglich oder nur aufgrund unbekannter oder Zero-Day-Exploits? Es würde helfen, die Bedrohung abzuschätzen.
    Schauen Sie sich die Firefox-Erweiterung "Firesheep" an, um zu erfahren, wie einfach es ist, Sitzungscookies zu stehlen.
    jpkrohling
    2013-10-14 17:12:24 UTC
    view on stackexchange narkive permalink

    Gehen Sie nicht davon aus, dass ein Dienst eine Zeitüberschreitung aufweist. Selbst wenn es eine Zeitüberschreitung gibt, kann ein Angreifer einfach Ihr Cookie sammeln und es mit einem einfachen Skript verwenden, das den Dienst weiter pingt, Ihr Cookie sendet und den "zuletzt gesehenen" Zeitstempel aktualisiert. Es gibt verschiedene Möglichkeiten für Websitebesitzer, sich davor zu schützen, aber vertrauen Sie den Websitebesitzern nicht. Das Stehlen eines Cookies ist nicht so schwer, wie es sich anhört (eine Suche auf Youtube zeigt Ihnen möglicherweise genau, wie einfach es ist), und Ihr bester Schutz für diesen Fall besteht in der Tat darin, sich abzumelden.

    Kees de Wit
    2013-10-14 23:24:20 UTC
    view on stackexchange narkive permalink

    Wenn Sie sich nicht abmelden, bleibt das Anmeldecookie für einen bestimmten Zeitraum gültig (abhängig von der Implementierung), da der Server (auf dem die Webanwendung ausgeführt wird) nicht weiß, dass Sie Ihren Browser geschlossen haben. Wenn jemand Ihr Cookie gestohlen hat, kann er sich damit bei der Anwendung anmelden und sogar die Gültigkeit verlängern, da die meisten Implementierungen einen gleitenden Ablauf haben.

    AquaAlex
    2013-10-15 11:55:43 UTC
    view on stackexchange narkive permalink

    Aus Sicherheitsgründen ist die Antwort meiner Meinung nach einfach. Wenn Sie mit dem Abmelden einer Site fertig sind. Und wenn Sie mit dem Surfen fertig sind, löschen Sie Ihren Cache und löschen Sie den Verlauf usw. Sie können Ihren Browser sogar so einrichten, dass beim Schließen des Browsers alles gelöscht wird. Hinterlassen Sie so wenig Spuren wie möglich von dem, was Sie getan haben.

    Und klicken Sie bitte nicht auf Popups oder lustige Links in E-Mails. Achten Sie auf Weiterleitungen von der Site, auf der Sie sich zu einer anderen Site befinden.



    ⓘ
    Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
    Loading...