Programmiertechnik - Loginscript und Zurückbutton des Browsers

[Erri]

Hallo,

ich habe folgendes Problem mit meinem Login-Script bzgl. dem Logout und der anschließenden
Betätigung des Zurückbuttons des Browsers (bis zum erneutem Senden des Login-Formulars)

Vorgehensweise:
1. User loggt sich ein (dabei werden Sessionvariablen registriert)... -> login.php
2. Er besucht "sichere" Seiten -> z.B. secret.php
3. Anschließend loggt er sich aus -> logout.php

Alle Dateien beinhalten folgenden Code, um Cache zu verhindern:

  
  header ("Expires: 0"); // Datum der Vergangenheit  
  header ("Last-Modified: " . gmdate ("D, d M Y H:i:s") . " GMT"); // immer geändert  
  header ("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1  
  header ("Pragma: no-cache"); // HTTP/1.0  

Die Datei secret.php enthält u.a. folgenden Code:

  
if(session_is_registered('login_user')){  
   $status = 1;  //eingeloggt  
}  
else{  
   header('Location: /login.php');  
}  

Wird nun (nach dem Logout) das 1. Mal der Zurück Button aufgerufen (also zurück zur secret.php),
wird der User lt. o.g. Code auch zum Login-Formular geleitet...

BIS HIERHIN FUNKTIONIERT ALSO ALLES SO WIE ICH ES MÖCHTE

JETZT DAS PROBLEM
Betätigt der User nun ein 2. Mal den Zurück Button des Browsers (also nun von der secret.php zurück zur login.php),
"kann" der User das Login Formular erneut senden und ist somit trotzdem wieder eingeloggt.

Bsp.: http://test.desteiger.de/secret.php
      Benutzername: test
      Passwort: gast

Kann man dies irgendwie programmiertechnisch umgehen?
Ich habe zwar schon viel probiert (z.B. datenbankgestützt - Session_ID, User-ID, Timestamp in Datenbank schreiben;
oder auch nach dem  Logout eine neue Session-ID erzeugen) aber ich komme einfach nicht zum gewünschten Ergebnis.

Funktionieren sollte es so, wie beispielsweise bei GMX...

Beim googlen finde ich immer nur die Lösung mit dem Code zur Verhinderung des Caches (siehe oben).
Dies funktioniert leider nur bis dahin, wie mit erneutem Betätigen des Zurückbuttons die login.php nicht erneut
aufgerufen und somit die Logindaten nicht erneut gesendet werden. (Im Beispiel also bis zur secret.php)

Würde mich freuen, wenn mir jemand weiterhelfen könnte.

Vielen Dank
Erri

[Nadja]

Hallo Erri,

kleine, bescheidene Frage:
Wie funktioniert das überhaupt, dass du den Zurück-Button des Browsers quasi "manipulierst"??

Liebe Grüße,
Nadja

[Erri]

Hi Nadja,

kleine, bescheidene Frage:
Wie funktioniert das überhaupt, dass du den Zurück-Button des Browsers quasi "manipulierst"??

Ich möchte den Zurückbutton nicht manipulieren.
Es ist mir klar, dass das nicht geht. Zumindest nicht mit PHP, weil PHP eine serverseitige Sprache ist.

Was ich möchte, ist eine Lösung finden, damit nach dem erneutem Laden der Login-Seite und somit der erneute Login (in meinem Bsp. wurde also nach dem Logout 2x der Zurückbutton betätigt) eine Meldung ausgeben, die sinngemäß beinhaltet, dass die Session abgelaufen ist (wie eben auch bei GMX).
Also möchte ich den User dazu bewegen, sich erneut anzumelden...

Ich hoffe, du verstehst, was ich meine ;-)

Viele Grüße und Vielen Dank,
Erri

[Nadja]

Hallo Erri,

Ich hoffe, du verstehst, was ich meine ;-)

Tue ich. Hab dafür aber leider keinen Lösungsansatz.

Ich raff nur nicht, wie du folgendes realisiert hast:
Nach dem einloggen kommt man auf die sichere Seite und loggt sich von da wieder aus.
Beim jetzigen, ersten Betätigen des Zurück-Buttons müsste man doch eigentlich auf die "sichere Seite" zurückkommen, aber man kommt zum Loginformular.

Wie hast du das gemacht??
Irgendwie hakt es da gerade bei mir ganz gewaltig ;)

Liebe Grüße,
Nadja

[Erri]

Hi Nadja,

Ich raff nur nicht, wie du folgendes realisiert hast:
Nach dem einloggen kommt man auf die sichere Seite und loggt sich von da wieder aus.
Beim jetzigen, ersten Betätigen des Zurück-Buttons müsste man doch eigentlich auf die "sichere Seite" zurückkommen, aber man kommt zum Loginformular.

Wie hast du das gemacht??
Irgendwie hakt es da gerade bei mir ganz gewaltig ;)

Na ich überprüfe ob die Sessionvariable noch registriert ist, sonst leite ich zum Loginformular weiter:

  
if(session_is_registered('login_user')){  
    $status = 1;  //eingeloggt  
}  
else{  
    header('Location: /login.php');  
}  

Wichtig ist, dass in der "sicheren" Seite kein Cache erlaubt ist.
Hierfür dieser Code:

  
header ("Expires: 0"); // Datum der Vergangenheit  
header ("Last-Modified: " . gmdate ("D, d M Y H:i:s") . " GMT"); // immer geändert  
header ("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1  
header ("Pragma: no-cache"); // HTTP/1.0  

PS.: Ich würde mich freuen, wenn jemand ein Lösungsansatz für mein Problem hat...

Viele Grüße und Vielen Dank,
Erri

[Nadja]

Hallo Erri,

Na ich überprüfe ob die Sessionvariable noch registriert ist, sonst leite ich zum Loginformular weiter:

Na klar, ist ja auch eigentlich logisch *endlich hat es bei mir klick gemacht* :)

Danke für deine Antwort!

Liebe Grüße,
Nadja

[Dennis]

Hi Erri,

Betätigt der User nun ein 2. Mal den Zurück Button des Browsers (also nun von der secret.php zurück zur login.php),
"kann" der User das Login Formular erneut senden und ist somit trotzdem wieder eingeloggt.

Ja, "kann" - aber mein Browser fragt mich ja, ob ich die Daten nochmal versenden will oder nicht, wähle ich da "ja" aus, dann will ich mich auch wieder einloggen - warum willst du mir das dann verbieten?

MfG, Dennis.

[Erri]

Hi Dennis,

Ja, "kann" - aber mein Browser fragt mich ja, ob ich die Daten nochmal versenden will oder nicht, wähle ich da "ja" aus, dann will ich mich auch wieder einloggen - warum willst du mir das dann verbieten?

Naja, ich wollte vermeiden, dass man sich ohne erneute Eingabe von Benutzername und Passwort erneut anmelden kann.
Ich dachte daran, dass wenn du "ja" ausgeählt hast (bzw. F5 im I.E. betätigt hast), das Login-Formular mit einer Meldung "Session ist abgelaufen" angezeigt wird, sodass du dich erneut identifizieren musst, so wie es bei z.B. Webmailing üblich ist.

Viele Grüße und Vielen Dank,
Erri

[Christoph Zurnieden]

Hi,

Ja, "kann" - aber mein Browser fragt mich ja, ob ich die Daten nochmal versenden will oder nicht, wähle ich da "ja" aus, dann will ich mich auch wieder einloggen - warum willst du mir das dann verbieten?

Naja, ich wollte vermeiden, dass man sich ohne erneute Eingabe von Benutzername und Passwort erneut anmelden kann.

Das ist das Problem des Benutzers nicht Deines.

Ich dachte daran, dass wenn du "ja" ausgeählt hast (bzw. F5 im I.E. betätigt hast), das Login-Formular mit einer Meldung "Session ist abgelaufen" angezeigt wird, sodass du dich erneut identifizieren musst, so wie es bei z.B. Webmailing üblich ist.

Ich weiß nicht warum die das machen, kann nicht sagen, das es üblich ist und halte es für einen Bug, den es zu reparieren und nicht nachzuahmen gilt.
Nein, so wie Du das jetzt hast ist das nicht nur i.O. sondern sogar genau richtig.

Na, _ganz_ richtig ist es nicht: Location verlangt nach HTTP/1.x eine absolute URI. Siehe RFC 1945,10.11 bzw RFC 2617,14.30.

so short

Christoph Zurnieden

[Erri]

Hi Christoph,

Das ist das Problem des Benutzers nicht Deines.

Das habe ich bisher so noch nicht gesehen.
Aber warum soll sich der User dann überhaupt ausloggen, wenn die Session sowieso mit dem Schließen des Browserfensters beendet wird? Dann wäre ein Logout, bei dem lediglich die Session zerstört wird, ja "für die Katz", wenn man mit ein paar "Zurück-Klicks" wieder eingeloggt ist, oder?
[Aber der User muss ja dem erneuten Senden des Formulars zustimmen, ich weiß :) - mit Ja - oder im I.E. mit F5]

Ich dachte daran, dass wenn du "ja" ausgeählt hast (bzw. F5 im I.E. betätigt hast), das Login-Formular mit einer Meldung "Session ist abgelaufen" angezeigt wird, sodass du dich erneut identifizieren musst, so wie es bei z.B. Webmailing üblich ist.
Ich weiß nicht warum die das machen, kann nicht sagen, das es üblich ist und halte es für einen Bug, den es zu reparieren und nicht nachzuahmen gilt.
Nein, so wie Du das jetzt hast ist das nicht nur i.O. sondern sogar genau richtig.

Du meinst ein Bug des Browsers? Mmh, na dann werde ich es so lassen.

Na, _ganz_ richtig ist es nicht: Location verlangt nach HTTP/1.x eine absolute URI. Siehe RFC 1945,10.11 bzw RFC 2617,14.30.

Das wusste ich bisher nicht. Aber ich habe es gerade in den Lösungen des SELFHTML-Gewinnspiels gelesen ;-)
Ich werde es ergänzen.

so short

aja ;-)

Merci,
Erri

[Christoph Zurnieden]

Hi,

Das ist das Problem des Benutzers nicht Deines.
Das habe ich bisher so noch nicht gesehen.

Ja, das haben wir uns schon gedacht ;-)

Aber warum soll sich der User dann überhaupt ausloggen, wenn die Session sowieso mit dem Schließen des Browserfensters beendet wird?

Erstens wird es das nicht, da Du nicht sicher feststellen kannst, wann ein Browserfenster geschlossen wird und zweitens ist ausloggen stets ein guter Stil.

Dann wäre ein Logout, bei dem lediglich die Session zerstört wird, ja "für die Katz", wenn man mit ein paar "Zurück-Klicks" wieder eingeloggt ist, oder?

Warum? Ist doch angenehm, das man sich so einfach wieder einloggen kann, falls man mal 'was vergessen hat. Denn es ist ja bekanntermaßen so, das einem sowas immer genau dann einfällt wenn es just zu spät ist. Jedwede Hürde ist da unpassend.

[Aber der User muss ja dem erneuten Senden des Formulars zustimmen, ich weiß :) - mit Ja - oder im I.E. mit F5]

Ach, ich glaube so langsam zu verstehen: Du hast Angst, das da jemand Unsinn mit anstellen könnte? Nun, da kannst Du nichts dran machen, das ist wirklich ausschließliches Problem des Nutzers, da hast Du nix mit am Hut.

Du meinst ein Bug des Browsers? Mmh, na dann werde ich es so lassen.

Nein, kein Bug des Browser (höchstens der Einstellungen, wenn es das ist, was ich oben vermutete). Nein, es ist ein Bug des Anbieters, das er es nicht schafft ein sauberes wiederholtes Login bereitzustellen. Eine Fehlermeldung wie von Dir beschrieben ist eindeutig ein Bug in des Anbieters Software.

Na, _ganz_ richtig ist es nicht: Location verlangt nach HTTP/1.x eine absolute URI. Siehe RFC 1945,10.11 bzw RFC 2617,14.30.
Das wusste ich bisher nicht. Aber ich habe es gerade in den Lösungen des SELFHTML-Gewinnspiels gelesen ;-)
Ich werde es ergänzen.

Du könntest auch Deine Quelle darüber informieren, damit es zumindest einmal weniger falsch im Netz steht ,-)

so short

Christoph Zurnieden

[Erri]

Hi ,

Erstens wird es das nicht, da Du nicht sicher feststellen kannst, wann ein Browserfenster geschlossen wird und zweitens ist ausloggen stets ein guter Stil.

Stimmt, ich gebe dir Recht.

Warum? Ist doch angenehm, das man sich so einfach wieder einloggen kann, falls man mal 'was vergessen hat. Denn es ist ja bekanntermaßen so, das einem sowas immer genau dann einfällt wenn es just zu spät ist. Jedwede Hürde ist da unpassend.

Wenn man es so betrachtet, stimmt es. Ich habe es bisher aus (nennen wir es) Sicherheitsgründen anders betrachtet --> z.B. (auch wenn`s ein Dummes ist *g*) eine liebe Mitarbeiterin loggt sich aus und lässt das Browserfenster offen... ein netter Kollege geht ran, klickt ein paar mal zurück und ist wieder eingeloggt...

Ach, ich glaube so langsam zu verstehen: Du hast Angst, das da jemand Unsinn mit anstellen könnte? Nun, da kannst Du nichts dran machen, das ist wirklich ausschließliches Problem des Nutzers, da hast Du nix mit am Hut.

OK, es ist immer gut, wenn man nichts mit zu tun hat ;-)

Nein, kein Bug des Browser (höchstens der Einstellungen, wenn es das ist, was ich oben vermutete). Nein, es ist ein Bug des Anbieters, das er es nicht schafft ein sauberes wiederholtes Login bereitzustellen. Eine Fehlermeldung wie von Dir beschrieben ist eindeutig ein Bug in des Anbieters Software.

Also haben mehrere Webmailanbieter Bugs in ihren Loginscripts(?)

Na, _ganz_ richtig ist es nicht: Location verlangt nach HTTP/1.x eine absolute URI. Siehe RFC 1945,10.11 bzw RFC 2617,14.30.
Das wusste ich bisher nicht. Aber ich habe es gerade in den Lösungen des SELFHTML-Gewinnspiels gelesen ;-)
Ich werde es ergänzen.

Du könntest auch Deine Quelle darüber informieren, damit es zumindest einmal weniger falsch im Netz steht ,-)

Meine Quelle ist Confixx, also sozusagen die Firma SWsoft :-)

Viele Grüße und Vielen Dank,
Erri

[Christoph Zurnieden]

Hi,

Wenn man es so betrachtet, stimmt es. Ich habe es bisher aus (nennen wir es) Sicherheitsgründen anders betrachtet --> z.B. (auch wenn`s ein Dummes ist *g*) eine liebe Mitarbeiterin loggt sich aus und lässt das Browserfenster offen... ein netter Kollege geht ran, klickt ein paar mal zurück und ist wieder eingeloggt...

Ist normalerweise für beide Seiten ein Grund für eine fristlose Kündigung.
Gut, das war jetzt mehr Wollen als Sein ... ;-)

Also haben mehrere Webmailanbieter Bugs in ihren Loginscripts(?)

Wenn diese Fehlermeldung kommt, dann ist davon auszugehen, ja.

Du könntest auch Deine Quelle darüber informieren, damit es zumindest einmal weniger falsch im Netz steht ,-)
Meine Quelle ist Confixx, also sozusagen die Firma SWsoft :-)

Dann kennst Du ja den Schuldigen: proprietäre Software.
SCNR >;->

so short

Christoph Zurnieden

[Martin Hölter]

Hi!

Naja, ich wollte vermeiden, dass man sich ohne erneute Eingabe von Benutzername und Passwort erneut anmelden kann.

Das ist das Problem des Benutzers nicht Deines.

Wenn wir so denken würden, hätten wir ein Problem...

Gruß aus Iserlohn

Martin

[Christoph Zurnieden]

Hi,

Naja, ich wollte vermeiden, dass man sich ohne erneute Eingabe von Benutzername und Passwort erneut anmelden kann.

Das ist das Problem des Benutzers nicht Deines.

Wenn wir so denken würden, hätten wir ein Problem...

Wer ist "wir" und um was für ein Problem handelt es sich genau?

so short

Christoph Zurnieden

[Erri]

Hi Christoph, Hi Martin,

Naja, ich wollte vermeiden, dass man sich ohne erneute Eingabe von Benutzername und Passwort erneut anmelden kann.

Das ist das Problem des Benutzers nicht Deines.

Wenn wir so denken würden, hätten wir ein Problem...

Wer ist "wir" und um was für ein Problem handelt es sich genau?

Ich schätze mal, dass mit "wir" die Sparkasse Iserlohn gemeint ist... (siehe Website Link bei Martin.)

Mich würde ebenfalls interessieren, welches Problem das ist?

@Martin - Kannst du mir denn sagen, wie es die Sparkasse (oder auch eine Bank allgemein, die Online-Banking betreibt) handhabt?
Interessieren würde mich es schon :-)

Viele Grüße und Vielen Dank,
Erri

[Martin Hölter]

Hi!

Wer ist "wir" und um was für ein Problem handelt es sich genau?
Ich schätze mal, dass mit "wir" die Sparkasse Iserlohn gemeint ist... (siehe Website Link bei Martin.)

Genau. Wir sind die Sparkasse und das Problem ist das Online-Banking, wo ja auch ein Login gefordert wird. Man stelle sich nur den Aufschrei vor, wenn bei Planetopia darüber berichtet wird, wie einfach man doch Online-Banking-Systeme knacken kann, indem man einfach die Zurück-Tasten des Browsers benutzt.

@Martin - Kannst du mir denn sagen, wie es die Sparkasse (oder auch eine Bank allgemein, die Online-Banking betreibt) handhabt?
Interessieren würde mich es schon :-)

Ausgeloggt ist ausgeloggt. Da hilft auch kein "Zurück" und neu laden. Wie dies bei uns technisch realisiert wurde, weiß ich leider nicht, das Online-Banking schreibe ich nicht selbst.

Gruß aus Iserlohn

Martin

[Christoph Zurnieden]

Hi!

Hi,

Genau. Wir sind die Sparkasse und das Problem ist das Online-Banking, wo ja auch ein Login gefordert wird. Man stelle sich nur den Aufschrei vor, wenn bei Planetopia darüber berichtet wird, wie einfach man doch Online-Banking-Systeme knacken kann, indem man einfach die Zurück-Tasten des Browsers benutzt.

Das wäre zwar völliger Humbug, jedoch schlecht für das Image des Onlinebankings das ja hauptsächlich der (bei Sparkassen nicht so ganz koscheren) Gewinnoptimierung dient.
Es ist also kein technisches Problem und deshalb auch nicht mit technischen Mitteln lösbar.
Jeglicher Workaround ist bloße Augenwischerei.

Allerdings hat es in vergangener Zeit echte und auch noch  erhebliche Sicherheitslücken beim Onlinebanking gegeben, die weder die Runde machten, geschweige denn einen Aufschrei verursachten, und ausreichend viele Leute von der Benutzung abhielten, das es sich nicht mehr lohnt.

Ausgeloggt ist ausgeloggt. Da hilft auch kein "Zurück" und neu laden.

Das heißt ja, das man sich gar nicht mehr einloggen kann. Das ist aber nicht der Fall. Es wird nur ein Würgaround eingebastelt, der es verhüten soll, das sich jemand per Back-Button neu einloggt. Was durch eine Einstellung des Browsers ermöglicht wird, also durch eine freie Entscheidung des Benutzers[1].

Es tut mit leid, aber für mich ist das immer noch aus technischer Sicht völlig hanebüchen und sinnlos.
Aber wie Du schon richtig sagtest gibt es dafür andere als technische Gründe, die auch ausreichen können sowas zu implementieren und die sogar ich zähneknirschend und unter heftigem Protest akzeptieren muß.

Nun mein lieber Erri, trifft so ein Grund zu?
Dann versuche es einmal damit, die Session-ID bereits vor dem Login zu vergeben, sprich: bereist das Loginformular läuft über Sessions (z.B. per "hidden" o.ä.). Ist dann die Session abgelaufen nach dem Ausloggen wird die Abgelaufenen beim Back-Button-Login nochmal benutzt und triggert besagten Fehler.

Diese Methode ist übrigens nicht sicher! Es ist ein bloßer Würgaround, die von Dir verlangte Fehlermeldung zu produzieren!

so short

Christoph Zurnieden

[1] Ja, mir ist durchaus klar, was jetzt eingeworfen werden könnte, ich erlebe es ja fast täglich selber *sigh*

[Martin Hölter]

Hi!

Man stelle sich nur den Aufschrei vor, wenn bei Planetopia darüber berichtet wird, wie einfach man doch Online-Banking-Systeme knacken kann, indem man einfach die Zurück-Tasten des Browsers benutzt.

Das wäre zwar völliger Humbug, jedoch schlecht für das Image des Onlinebankings das ja hauptsächlich der (bei Sparkassen nicht so ganz koscheren) Gewinnoptimierung dient.

Humbug ist es sowieso, aber das stört ja manche Sender nicht, sowas zu senden (gibt ja auch genug BILD-Leser).

Zur Gewinnoptimierung: was ist denn daran bei Sparkassen "nicht koscher" (OK, wir lassen die Kunden nicht ausbluten wie andere ;-) )? Der Zweck einer Sparkasse ist es zwar nicht, Gewinne zu machen, allerdings muss auch eine Sparkasse wachsen, um den Kreditbedarf decken zu können (Basel II sei da nur mal als Stichwort genannt). Und wodurch wächst man? Richtig - Gewinne.

Die Gewinnerzielung steht zwar bei uns nicht im Vordergrund, aber wir müssen auch sehen, wo wir bleiben.

Übrigens werden die meisten gewerblichen Websites mit Gewinnerzielungsabsicht betrieben ;-)

Allerdings hat es in vergangener Zeit echte und auch noch  erhebliche Sicherheitslücken beim Onlinebanking gegeben, die weder die Runde machten, geschweige denn einen Aufschrei verursachten, und ausreichend viele Leute von der Benutzung abhielten, das es sich nicht mehr lohnt.

Aha. Echte und erhebliche Sicherheitslücken? Bitte konkretisieren, ich kenne nicht eine.

Es wird nur ein Würgaround eingebastelt, der es verhüten soll, das sich jemand per Back-Button neu einloggt.
Was durch eine Einstellung des Browsers ermöglicht wird, also durch eine freie Entscheidung des Benutzers[1].

Nein, in 99 % aller Fälle durch die Default-Einstellungen. Und da das Online-Banking nunmal ein sensibles Thema ist, muss[tm] der User hier bevormundet[tm] werden. Ich wüsste übrigens im Moment auch nicht, wo ich diesbezüglich etwas einstellen könnte.

Gruß aus Iserlohn

Martin

[Erri]

Hi,

Nun mein lieber Erri, trifft so ein Grund zu?

*g* Nun, ich glaube kaum, dass sich irgendeine TV-Anstalt oder ein Zeitschriftenverlag mit dem Login bzw. Logout meiner "unwichtigen" Webseite beschäftigen wird. ;-)
"Unwichtig" deshalb, weil es beim Online-Banking bekannter Weise anders aussieht. Ich sehe es mittlerer Weile jedoch auch als Humbug, so einen "Würgaround", wie du so schön schreibst, hinein zu basteln.

Dann versuche es einmal damit, die Session-ID bereits vor dem Login zu vergeben, sprich: bereist das Loginformular läuft über Sessions (z.B. per "hidden" o.ä.). Ist dann die Session abgelaufen nach dem Ausloggen wird die Abgelaufenen beim Back-Button-Login nochmal benutzt und triggert besagten Fehler.

Diese Methode ist übrigens nicht sicher! Es ist ein bloßer Würgaround, die von Dir verlangte Fehlermeldung zu produzieren!

Eventuell probier ich es mal aus. Ich werde es jedoch aus von dir o.g. Grund nicht in der "Produktivseite" verwenden.

Vielen Dank für die hilfreichen Tipps,
Erri

[Christoph Zurnieden]

Hi,

Zur Gewinnoptimierung: was ist denn daran bei Sparkassen "nicht koscher" (OK, wir lassen die Kunden nicht ausbluten wie andere ;-) )?

Nein, mein Ausdruck war "nicht ganz koscher". Alles legal zwar aber durchaus fraglich ob Ausmaß und Mittel so ganz im Sinne des Erfinders sind. Es bürgt bei Sparkassen der Staat also der Bürger also der Kunde. Jegliche Gewinnoptimierung dient also der Sicherheit der Kunden. Problem ist, das sie nicht so ganz in den Genuß der Überschüsse kommen, wie eigentlich vorgesehen.
Aber ich schweife ab, darum geht es ja gar nicht.

Übrigens werden die meisten gewerblichen Websites mit Gewinnerzielungsabsicht betrieben ;-)

Zumindest deutsche sollten es tun, denn sonst mag das Finanzamt nicht mehr mitspielen ;-)

Allerdings hat es in vergangener Zeit echte und auch noch  erhebliche Sicherheitslücken beim Onlinebanking gegeben, die weder die Runde machten, geschweige denn einen Aufschrei verursachten, und ausreichend viele Leute von der Benutzung abhielten, das es sich nicht mehr lohnt.

Aha. Echte und erhebliche Sicherheitslücken? Bitte konkretisieren, ich kenne nicht eine.

Zu schwache und teilweise auchschlecht implementierte Verschlüsselung. Siehe WarenTEST-Heft von ... ach schau' selber, dafür geb' ich jetzt kein Geld aus ;-)

Was durch eine Einstellung des Browsers ermöglicht wird, also durch eine freie Entscheidung des Benutzers[1].

Nein, in 99 % aller Fälle durch die Default-Einstellungen.

Wofür fummel ich eigentlich Fußnoten, wenn sie doch keiner liest? ;-)
Aber streng genommen ist auch das Belassen der Defaulteinstellungen eine freie Willensentscheidung des Benutzers.

Und da das Online-Banking nunmal ein sensibles Thema ist, muss[tm] der User hier bevormundet[tm] werden.

Weil ihr ansonsten Geld verliert, ja.
_Das_ juckt den Benutzer aber eigentlich wenig >;->

Ich wüsste übrigens im Moment auch nicht, wo ich diesbezüglich etwas einstellen könnte.

Dann ist also der Browser beschädigt? (Ja, auch eine fehlende oder unvollständige Betriebsanleitung ist ein Fehler und hat Anspruch auf Garantieleistung)

so short

Christoph Zurnieden

[Martin Hölter]

Hi!

Es bürgt bei Sparkassen der Staat also der Bürger also der Kunde.

Falsch. Vor 19 Tagen hattest du aber noch Recht ;-)

Jegliche Gewinnoptimierung dient also der Sicherheit der Kunden. Problem ist, das sie nicht so ganz in den Genuß der Überschüsse kommen, wie eigentlich vorgesehen.

Also ich finde es schon in Ordnung, wenn eine Sparkasse jährlich Tausende bis Millionen Euro spendet oder an die Stadt abführt.

Aber ich schweife ab, darum geht es ja gar nicht.

OK, ändern wir mal das Topic ;-)

Aha. Echte und erhebliche Sicherheitslücken? Bitte konkretisieren, ich kenne nicht eine.

Zu schwache und teilweise auchschlecht implementierte Verschlüsselung. Siehe WarenTEST-Heft von ... ach schau' selber, dafür geb' ich jetzt kein Geld aus ;-)

OK, wir nutzen nur ncoh aktuelle Verschlüsselungsverfahren, betrifft uns in dem Falle jetzt nicht.

Ich wüsste übrigens im Moment auch nicht, wo ich diesbezüglich etwas einstellen könnte.

Dann ist also der Browser beschädigt? (Ja, auch eine fehlende oder unvollständige Betriebsanleitung ist ein Fehler und hat Anspruch auf Garantieleistung)

Ich habe Wissen jetzt als "ich weiß es" und nicht als "ich weiß wo es steht" oder "ich kenne jemanden, der weiß wo es steht" definiert ;-)

Gruß aus Iserlohn

Martin

[Christoph Zurnieden]

Hi,

Es bürgt bei Sparkassen der Staat also der Bürger also der Kunde.

Falsch. Vor 19 Tagen hattest du aber noch Recht ;-)

Ist es das Gesetz, das bis spätestens 31. Dezember 2002 rechtswirksam umgesetzt werden mußte?
Ging ja richtig flott diesmal! >;->

Aber bei sowas bin ich auch selten aktuell informiert, ich sollte da also öfter mal nachschauen, _bevor_ ich mich in dem Themenbereich aus dem Fenster lehne, was? ;-)

Zu schwache und teilweise auchschlecht implementierte Verschlüsselung. Siehe WarenTEST-Heft von ... ach schau' selber, dafür geb' ich jetzt kein Geld aus ;-)

OK, wir nutzen nur ncoh aktuelle Verschlüsselungsverfahren, betrifft uns in dem Falle jetzt nicht.

Ich gehe davon aus, das es mittlerweile alle tun und den Rest erledigt Darwin ;-)

Meinen, leider etwas mageren Informationen zufolge ist bei vielen Banken mittlerweile entsprechend ausgebildetes Personal eingestellt worden. Daher nehme ich an, das auch die Pflege (Patches und grundsätzliche kryptographische Problem) kein Problem mehr darstellen sollte.

Ich habe Wissen jetzt als "ich weiß es" und nicht als "ich weiß wo es steht" oder "ich kenne jemanden, der weiß wo es steht" definiert ;-)

Nein, da bin ich doch etwas pragmatischer. Man kann schließlich nicht alles wissen, denn sonst wären ja Hilfe-Dateien Platzverschwendung. Es genügt, wenn man weiß wo es steht (oder einen Assistenten hat, der das für einen recherchiert ;-).
Insbesondere bei den eierlegenden Wollmilchsäuen von Windows-Software geht das kaum noch anders. Die Bedingung war bei Unix noch "Können" (es gibt eine Handvoll Tools für jeweils eine Aufgabe, eine Pipe und eine skriptfähige Shell. Mit Wissen kam man da nicht weit, man muß schon kreativ damit umgehen können) so ist es bei Windows "Wissen" (um dies und das zu machen klicke hier und da. Da ist keinerlei Kreativität nötig, nur noch Wissen. Das können selbst die Blagen. Ist nicht letzthin eines gefeiert worden, weil es mit seinen 10(?) Lenzen jüngster MSCE geworden ist?).
Und da Wissen den Vorteil hat auslagerbar zu sein, sollte man den auch nutzen.

so short

Christoph Zurnieden

[Erri]

Hi nochmal,

noch eine Ergänzung:

Dann versuche es einmal damit, die Session-ID bereits vor dem Login zu vergeben, sprich: bereist das Loginformular läuft über Sessions (z.B. per "hidden" o.ä.). Ist dann die Session abgelaufen nach dem Ausloggen wird die Abgelaufenen beim Back-Button-Login nochmal benutzt und triggert besagten Fehler.

So ähnlich hatte ich es bereits probiert.

Nach dem Logout hatte ich die Session-ID mit einem Status (z.B. beendet) in die DB geschrieben. Beim Login konnte ich dann kontrollieren, ob die Session beendet wurden ist und es war mir möglich, genannte Fehlermeldung (aus dem Wörgarround) auszugeben.

Der User konnte sich so zwar nicht mehr über den Zurückbutton einloggen, aber auch nicht mehr durch den neuen Aufruf der Loginseite, weil ja auch dort noch die gleiche Session-ID gesetzt war. (Also hätte der User das Browserfenster schließen und neu öffnen müssen.)
Erzeugte ich nun im Loginformular eine neue Session-ID, war auch wieder der Login über den Zurückbutton möglich, weil auch dann eine neue Session-ID erzeugt worden ist.

Also alles für die "Katz". *gr*

Viele Grüße und Vielen Dank,
Erri

[Christoph Zurnieden]

Hi,

Der User konnte sich so zwar nicht mehr über den Zurückbutton einloggen, aber auch nicht mehr durch den neuen Aufruf der Loginseite, weil ja auch dort noch die gleiche Session-ID gesetzt war. (Also hätte der User das Browserfenster schließen und neu öffnen müssen.)

Ein Reload der Seite sollte eine frische ID erhalten, denn der Reload ist ja dadurch identifizierbar, das er kein Benutzerdaten enthält. Genau wie beim erstem jungfräulichem Aufruf. Deshalb verstehe ich das nicht so ganz mit dem "Browserfenster schließen und neu öffnen".
Achso, ja, ich vergaß, sorry >;->

Erzeugte ich nun im Loginformular eine neue Session-ID, war auch wieder der Login über den Zurückbutton möglich, weil auch dann eine neue Session-ID erzeugt worden ist.

Nein, die Erzeugung sollte vorher passieren. Könntest natürlich auch mit dem Referrer herumspielen. Oder Du läßt das mit dem no-cache und experimentierst ein wenig mit Caching und Last-Modified et al. Dann wird eventuell (denn das ist natürlich auch nicht sicher) die ID nochmal gesendet -> Fehlermeldung.
Wahrscheinlich brauchst Du von allem ein bischen und mindestens eine Woche, damit Du dich durch alle Browser und Patchlevels durchprobiert hast auch wenn es IE-only ist.
Das alles für ein wenig Kosmetik?
Aber das Problem ist zumindest technisch interessant, ich schau mal, was sich anderweitig so findet.
Wenn ich denn das Problem in maximal 10 Begriffe packen kann ;-)

so short

Christoph Zurnieden

[Christoph Zurnieden]

Hi,

Wenn ich denn das Problem in maximal 10 Begriffe packen kann ;-)

http://www.google.de/search?q=login session back button&ie=UTF-8&oe=UTF-8
Erster Link:
http://www.phpforum.de/archiv_11674_Sessionwie%40verhindert%40man%40neuen%40Login%40ueber%40Browserback%40Button_anzeigen.html
(Dsa ist mit Absicht kein Link, denn das ist ein Popup/Formular/Dingenskirchen-chaos!)
Ich darf daraus zitieren:

"ok, ich hatte das gleiche problem, und habe lange gesucht, jetzt habe ich endlich die perfekte loesun gefunden. direkt nach dem login sendet man einen header an den client, der zu einer weiterleitung fuehrt. dann kann man die seite, an die die logindaten urspruenglich geschickt wurden, nicht mehr per zurueck button erreichen."

"Nach dem Abschicken der Daten prüfe ich ob Passwort und User richtig sind: wenn ja, mache ich einfach eine weiterleitung per header ("Location: ./"); auf die gleiche Seite. Schwupp sind die Login Daten per Browser-Back Button verschwunden!"

Ja, jetzt wo die's sagen, fällt's mir auch wie Schuppen aus den Haaren ;-)

So ganz korrekt ist es aber nicht, die Sache mit der "hidden ID" wäre schon sauberer, aber dafür braucht es ja zwei IDs und damit kostbare Entropie. Zudem sagtest Du, das es nicht funtkioniert (warum auch immer, so ganz verstehe ich es immer noch nicht, ich kann nur vermuten, das der IE mal wieder spinnt).

so short

Christoph Zurnieden

[Erri]

Guten Morgen noch einmal Christoph,

zunächst vielen Dank für deine hilfreiche Suche, ich habe dies letzte Woche nicht gefunden :->

"Nach dem Abschicken der Daten prüfe ich ob Passwort und User richtig sind: wenn ja, mache ich einfach eine weiterleitung per header ("Location: ./"); auf die gleiche Seite. Schwupp sind die Login Daten per Browser-Back Button verschwunden!"

Ja, jetzt wo die's sagen, fällt's mir auch wie Schuppen aus den Haaren ;-)

Boar, ich bin begeistert! Es ist doch eine annehmbare Lösung, nicht war? Und das Beste, es fungdschoniert sogar mit dem Mikkrosaft Indernet-Explodierer *ggg*

So ganz korrekt ist es aber nicht, die Sache mit der "hidden ID" wäre schon sauberer, aber dafür braucht es ja zwei IDs und damit kostbare Entropie.

Das stimmt schon, allerdings sehe ich die Weiterleitung nach dem Login als gute Lösung, die man dem User anbieten kann. Selbst wenn sich der User via "Back-Button" wieder einloggen kann, er wird ja vorher vom Browser gefragt und hat somit die Möglichkeit, selbst zu bestimmen...

Viele Grüße und nochmals vielen Dank,
Erri

[Christoph Zurnieden]

Hi,

zunächst vielen Dank für deine hilfreiche Suche, ich habe dies letzte Woche nicht gefunden :->

Ja, hin und wieder habe ich ein glückliches Händchen bei den Suchbegriffen.

Boar, ich bin begeistert! Es ist doch eine annehmbare Lösung, nicht war?

Wenn Du Location ordentlich mit absoluter URI versorgst: ja, zumindest besser als vorher.

Und das Beste, es fungdschoniert sogar mit dem Mikkrosaft Indernet-Explodierer *ggg*

Selten genug, was? ;-)

so short

Christoph Zurnieden