Usertracking, history.back, reload

[Sabine]

Hallo!

Ich habe folgendes Problem - habe eine Website (PHP/MySql) mit Online-Shop und Warenkorb. Um den jeweiligen Besucher möglichst eindeutig zu identifizieren arbeite ich mit Sessions - er bekommt eine SessionID und zusätzlich wird noch eine Art Timestamp mitgespeichert (in der MySQL-Datenbank). In der Datenbank habe ich also für jeden Besucher die SessionID und den Timestamp gespeichert, bewegt sich der User über die Links weiter wird der Timestamp in der Datenbank aktualisiert (alter Eintrag ist also weg). Die Variable Timestamp wird über den Url übergeben, wenn der User nun aber auch back drückt oder aktualisieren hat er einen Timestamp den es eigentlich nicht mehr gibt und er wird neu registriert - was ich nicht möchte, da er ja erkannt bleiben soll.

Nun meine eigenen Lösungsvorschläge - würde mich über euer Feedback freuen, was eurer Meinung nach am Besten ist bzw. über weitere Vorschläge:
1. Nicht UPDATE sonder INSERT: Alle Daten des Users speichern - die Abfrage würde damit nicht mehr ins Leere gehen, allerdings können hier recht schnell viele Einträge zusammenkommen und die Wahrscheinlichkeit, dass ein anderer auf die Userdaten kommt wird etwas größer.
2. Irgendwie das beeinflussen was in der history-Liste steht - aber wie? (z.B. das eben diese eine Variable automatisch erneuert wird).
3. Bei Zurück eine automatische Meldung generieren (also wenn Timestamp nicht stimmt, die den Benutzer darauf hinweist, dass die Seite so nicht erreicht werden kann (meines Erachtens Gefahr der Verärgerung der Besucher)

Damit bin ich leider mit meinem Latein am Ende und hoffe auf eure Tipps und Anregungen.

Danke im Voraus.
Sabine

[Mike Roth]

Hallo Sabine

1. Nicht UPDATE sonder INSERT: Alle Daten des Users speichern - die Abfrage würde damit nicht mehr ins Leere gehen, allerdings können hier recht schnell viele Einträge zusammenkommen und die Wahrscheinlichkeit, dass ein anderer auf die Userdaten kommt wird etwas größer.

Warum änderst Du die Identifizierung überhaupt. ID + Entry Time
sollte doch eindeutig sein. Warum behälst Du diese nicht bei, sondern änderst sie bei seiten wechsel ab?

3. Bei Zurück eine automatische Meldung generieren (also wenn Timestamp nicht stimmt, die den Benutzer darauf hinweist, dass die Seite so nicht erreicht werden kann (meines Erachtens Gefahr der Verärgerung der Besucher)

Ändert das etwas an der "Kennung"? Nein. Damit würdest Du die User nur verunsichern. Ich denke das ist die schlechteste Lösung.

Gruß
Mike

[Sabine]

Hallo Mike!

1. Nicht UPDATE sonder INSERT: Alle Daten des Users speichern - die Abfrage würde damit nicht mehr ins Leere gehen, allerdings können hier recht schnell viele Einträge zusammenkommen und die Wahrscheinlichkeit, dass ein anderer auf die Userdaten kommt wird etwas größer.

Warum änderst Du die Identifizierung überhaupt. ID + Entry Time
sollte doch eindeutig sein. Warum behälst Du diese nicht bei, sondern änderst sie bei seiten wechsel ab?

Ich denke mir, dass dies eine zusätzliche Sicherheit ist - selbst wenn ein anderer die ID und Entry Time erraten würde, müsste er eben in diesem MOment versuchen einzusteigen in dem der andere noch auf der Seite ist, denn sobald der weitergeht, hat sich die Time geändert.

3. Bei Zurück eine automatische Meldung generieren (also wenn Timestamp nicht stimmt, die den Benutzer darauf hinweist, dass die Seite so nicht erreicht werden kann (meines Erachtens Gefahr der Verärgerung der Besucher)

Ändert das etwas an der "Kennung"? Nein. Damit würdest Du die User nur verunsichern. Ich denke das ist die schlechteste Lösung.

Ja, ist es auch für mich - mir fehlt es leider nur an Lösungsalternativen, wie ich das umgehen könnte.

Grüße
Sabine

Gruß
Mike

[Korbinia Bachl]

Ich habe folgendes Problem - habe eine Website (PHP/MySql) mit Online-Shop und Warenkorb. Um den jeweiligen Besucher möglichst eindeutig zu identifizieren arbeite ich mit Sessions - er bekommt eine SessionID und zusätzlich wird noch eine Art Timestamp mitgespeichert (in der MySQL-Datenbank).

Hallo,

emm, warum registrierst du es wenn ein User kommt in der DB !?! das ist purer schwachsinn- es sorgt nur für DB overload... gib die sessionID einfach in der URL mit... wie es dir gefällt zb:

http://www.shop.de/seite1.htm?session=3294729874923742734977

http://www.shop.de/3294729874923742734977/seite1.htm

oder gar:

http://3294729874923742734977.shop.de/seite1.htm

-> dadurch hat nur der eine User die ID, wenn er zurückgeht isses wurscht und die DB hat viel weniger zu tun...

1. Nicht UPDATE sonder INSERT: Alle Daten des Users speichern - die Abfrage würde damit nicht mehr ins Leere gehen, allerdings können hier recht schnell viele Einträge zusammenkommen und die Wahrscheinlichkeit, dass ein anderer auf die Userdaten kommt wird etwas größer.

Blödsinn: noch mehr DB arbeit aber das gleiche ergebniss......

2. Irgendwie das beeinflussen was in der history-Liste steht - aber wie? (z.B. das eben diese eine Variable automatisch erneuert wird).

mittels PHP nicht möglich - zudem Browserspzifisch und normalerweise IMHO auch nicht möglich... auser vielleicht beim MS .. bzw. dessen sicherheitslöchern...

3. Bei Zurück eine automatische Meldung generieren (also wenn Timestamp nicht stimmt, die den Benutzer darauf hinweist, dass die Seite so nicht erreicht werden kann (meines Erachtens Gefahr der Verärgerung der Besucher)

der Besucher wird wirklich sauer sein....

Damit bin ich leider mit meinem Latein am Ende und hoffe auf eure Tipps und Anregungen.

siehe oben...

Danke im Voraus.
Sabine

Bitte Bitte,

ps: kuck dir mal http://www.whiskyworld.de an, ist alles auf PHP und MySQL - deine Probleme kennt es jedoch nicht da wie oben beschrieben funzt..

mfg

Korbinian Bachl
www.whiskyworld.de

[Sabine]

Hallo!

Hallo,

emm, warum registrierst du es wenn ein User kommt in der DB !?! das ist purer schwachsinn- es sorgt nur für DB overload... gib die sessionID einfach in der URL mit... wie es dir gefällt zb:

http://www.shop.de/seite1.htm?session=3294729874923742734977

http://www.shop.de/3294729874923742734977/seite1.htm

oder gar:

http://3294729874923742734977.shop.de/seite1.htm

Ja, das ist schon klar, ich wollte einfach etwas mehr Sicherheit einbauen, denn mit diesem System kann der Besucher wenn er Glück hat eine fremde ID erraten und in deren Warenkorb schnüffeln.

-> dadurch hat nur der eine User die ID, wenn er zurückgeht isses wurscht und die DB hat viel weniger zu tun...

Das ist klar.

1. Nicht UPDATE sonder INSERT:
   Blödsinn: noch mehr DB arbeit aber das gleiche ergebniss......

Ja, denke ich mir auch.

2. Irgendwie das beeinflussen was in der history-Liste steht - aber wie? (z.B. das eben diese eine Variable automatisch erneuert wird).

mittels PHP nicht möglich - zudem Browserspzifisch und normalerweise IMHO auch nicht möglich... auser vielleicht beim MS .. bzw. dessen sicherheitslöchern...

Hab es mir fast gedacht.

Bitte Bitte,

ps: kuck dir mal http://www.whiskyworld.de an, ist alles auf PHP und MySQL - deine Probleme kennt es jedoch nicht da wie oben beschrieben funzt..

Na ja, mein eigentliches Problem kennt die Site schon, die ich mit meiner Lösung (UserID + ändernder Timestamp) umgehen wollte, nämlich, dass ein anderer durch Böswilligkeit / Trial and error oder warum auch immer im Warenkorb eines anderen schnüffeln kann. Durch die zusätzliche Variante des Timestamps der sich bei jedem Link ändert könnte ich das Problem ja eindämmen.

lg
Sabine

mfg

Korbinian Bachl
www.whiskyworld.de

[Korbinian Bachl]

Hallo

also wenn du glaubst das session=30898d8a6ffe9597b9fc355be853f3f8 einfach so gefaked werden kann bzw ein andrer das ja erraten könnte dann spiel lotto - solltest du 12 mal hintereinander den 6er mit zusatzzahl haben dann hättest du es geschafft ! - tja so groß is die mathematische wahrscheinlichkeit...

mal ernsthaft - sicherheit ja: aber nur um den warenkorbinhalt ? - es werden keine personenbezogenen daten etc. damit eingeschweißt--- also ich halte es für sehr sicher, zumal du den string der auf
md5(rand()) basiert ja auch noch verschärfen könntest wie zb. md5(rand()*$IP*$anfangstime...)

also wenn das immernoch zu unsicher ist dann nimm den PC/ server und klemm ihn vom netz ab, denn die meisten sicherheitslöcher sind viel simpler und haben reelle auswirkungen...

mfg

Korbinian Bachl
www.whiskyworld.de

[Sabine]

Hallo Korbinian!

also wenn du glaubst das session=30898d8a6ffe9597b9fc355be853f3f8 einfach so gefaked werden kann bzw ein andrer das ja erraten könnte dann spiel lotto - solltest du 12 mal hintereinander den 6er mit zusatzzahl haben dann hättest du es geschafft ! - tja so groß is die mathematische wahrscheinlichkeit...

Ich weiß, dass die SessionID nicht wirklich einfach zu "erraten" ist. Meine Idee mit dem Timestamp kam eigentlich daher, da schon des öfteren im Forum darüber im Zusammenhang mit dem Ausspionieren eines fremden Warenkorbinhalts diskutiert wurde. Daher dann auch die Idee den Timestamp bei jedem Link zu ändern - denn hier wird die Wahrscheinlichkeit wohl schon sehr, sehr gering, dass von einem Link zum nächsten sich jemand zwischenschalten kann.

mal ernsthaft - sicherheit ja: aber nur um den warenkorbinhalt ? - es werden keine personenbezogenen daten etc. damit eingeschweißt--- also ich halte es für sehr sicher, zumal du den string der auf
md5(rand()) basiert ja auch noch verschärfen könntest wie zb. md5(rand()*$IP*$anfangstime...)

Ja, ist klar. Allerdings ist halt bei mir im Hinterkopf, dass ich sehr verärgert wäre, wenn ich meinen Warenkorb bestücke und auf einmal ist etwas im Warenkorb was ich nicht reingelegt habe - ich würde nichts bestellen auf der Website.

also wenn das immernoch zu unsicher ist dann nimm den PC/ server und klemm ihn vom netz ab, denn die meisten sicherheitslöcher sind viel simpler und haben reelle auswirkungen...

Das wäre eine gute Idee, aber wie schütze ich mich dann vor mir selbst? ;-)

Ich würde mich wirklich freuen über noch ein paar Meinungen zu diesem Thema - ist es sicher genug nur die SessionID zu verwenden oder sollte man zusätzlich vorsorgen?
Wenn ja wie?
a) einfach ein Timestamp dazu den ich auch mitschleppe
b) einen sich ändernden Timestamp (so wie von mir anfangs geplant?)
c) ????

Liebe Grüße
Sabine

mfg

Korbinian Bachl
www.whiskyworld.de

[Michael Schröpl]

Hi Sabine,

In der Datenbank habe ich also für jeden Besucher die SessionID
und den Timestamp gespeichert, bewegt sich der User über die Links
weiter wird der Timestamp in der Datenbank aktualisiert (alter
Eintrag ist also weg).

so weit komme ich noch mit.

Die Variable Timestamp wird über den Url übergeben, wenn der User nun
aber auch back drückt oder aktualisieren hat er einen Timestamp den
es eigentlich nicht mehr gibt

... und was Du auch erkennen kannst, wenn Dein timestamp eine Kleiner-Gleich-Relation erfüllt.

und er wird neu registriert

Warum?
Du weißt, daß der Benutzer bereits angemeldet ist - durch den Inhalt
Deiner Datenbank.
Du weißt auch, daß der Benutzer einen kleineren time stamp gesendet hat
als in einem vorherigen Request, daß er also irgendwie zurück gegangen
ist.
Nun mach das Beste daraus, was die Logik Deiner Dialogführung hergibt.
Und das ist bestimmt nicht, diesen Benutzer neu anzumelden. Sowohl eine
Fehlermeldung aus auch ein vollständiges Transaktionsprotokoll (siehe
unten) dürften besser sein.

• was ich nicht möchte, da er ja erkannt bleiben soll.

Denke ich auch. Denn das Speichern der Session dürfte in meinen Augen
vor allem dazu dienen, ein Mehrfach-Login zu verhindern ... richtig?

1. Nicht UPDATE sonder INSERT: Alle Daten des Users speichern

Das wäre ein Weg, das Problem zu lösen - darauf werde ich noch eingehen.

• die Abfrage würde damit nicht mehr ins Leere gehen

_Das_ sollte sie auf keinen Fall.

allerdings können hier recht schnell viele Einträge zusammenkommen

... die Du alle in Deiner Datenbank speichern mußt ...

und die Wahrscheinlichkeit, dass ein anderer auf die Userdaten kommt
wird etwas größer.

Das sollte natürlich überhaupt nicht so ohne weiteres möglich sein.
Du kannst ja in die Session-ID auch Informationen mit hinein codieren,
die aus dem Verbindungsaufbau selbst stammen - sagen wir mal: Die IP-
Adresse des Client und/oder bestimmte HTTP-Header seines Browsers) -
und dies ebenfalls beim Decodieren der ID prüfen.
Das Hineinspringen in eine fremde Transaktion sollte schwieriger sein
als das Erraten Deines Session-ID-Algorithmus.

2. Irgendwie das beeinflussen was in der history-Liste steht - aber
   wie? (z.B. das eben diese eine Variable automatisch erneuert wird).

Ungern. Der Benutzer wird irgendwas tun, was er glaubt, tun zu wollen.
Alles, was Du sinnvollerweise tun darfst, ist, zu erkennen, was er will
und darauf so gut wie möglich reagieren.

Wenn ein Benutzer "zurück" will, dann will er zurück - die Frage ist,
wie gut Du die Session an derjenigen Stelle, wo er nun in eine andere
Richtung abbiegen will, sinnvollerweise weiter machen kannst.

Vielleicht brauchst Du wirklich in der Datenbank ein vollständiges
Protokoll aller HTTP-Requests des Benutzers, welche Du über die
Session-ID exakt erkennen kannst - dann kannst Du beim Eintreffen
eines Requests mit einer "alten" Session-ID alle Datenbankeinträge
mit "neueren" Session-IDs verwerfen und an der entsprechenden Stelle
weiter machen.
(Eine Datenbank würde in ihrem rollback-Segment etwa dasselbe tun,
um transaktionsfähig zu sein - sie muß allerdings nicht an beliebigen
Stellen aufsetzen, sondern nur den gesamten "Film" zurück spielen
können, falls die Transaktion abgebrochen wird.)

3. Bei Zurück eine automatische Meldung generieren (also wenn
   Timestamp nicht stimmt, die den Benutzer darauf hinweist, dass die
   Seite so nicht erreicht werden kann (meines Erachtens Gefahr der
   Verärgerung der Besucher)

Immer noch besser, als wenn der Benutzer andere Daten in seiner Shop-
Transaktion verarbeitet, als er selber glaubt.
Wenn der Kunde dann wegen eines fehlerhaften Shop-Systems einen Artikel
kauft, den er eigentlich durch "zurück" doch nicht haben wollte, wirst
Du nicht glücklich sein - denn dann ist der mal Kunde gewesen ...

Viele Grüße
      Michael

[Sabine]

Hallo Michael!

In der Datenbank habe ich also für jeden Besucher die SessionID
und den Timestamp gespeichert, bewegt sich der User über die Links
weiter wird der Timestamp in der Datenbank aktualisiert (alter
Eintrag ist also weg).

so weit komme ich noch mit.

:) na wenigstens kann ich klar formulieren, wenn ich schon nicht mehr klar denken kann ...

Die Variable Timestamp wird über den Url übergeben, wenn der User nun
aber auch back drückt oder aktualisieren hat er einen Timestamp den
es eigentlich nicht mehr gibt

... und was Du auch erkennen kannst, wenn Dein timestamp eine Kleiner-Gleich-Relation erfüllt.

Das ist eine gute Idee ... ich bin vielleicht eine Schlaue ... da ich den Timestamp mit md5() codiert habe bin ich auf die Idee bis dato gar nicht gekommen.

und er wird neu registriert

Nun mach das Beste daraus, was die Logik Deiner Dialogführung hergibt.
Und das ist bestimmt nicht, diesen Benutzer neu anzumelden. Sowohl eine
Fehlermeldung aus auch ein vollständiges Transaktionsprotokoll (siehe
unten) dürften besser sein.

Da hast du Recht.

• was ich nicht möchte, da er ja erkannt bleiben soll.

Denke ich auch. Denn das Speichern der Session dürfte in meinen Augen
vor allem dazu dienen, ein Mehrfach-Login zu verhindern ... richtig?

Login gibt es hier noch nicht - der Kunde shoppt wie er will (ausser er hat schon mal bestellt und akzeptiert das seine Daten in einem Cookie gespeichert werden, dann kenne ich ihn von Anfang an). Ansonsten kenne ich den Kunden erst nachdem er beschließt, dass was er in den Warenkorb gelegt hat zu bestellen. Dann wird er neu registriert oder eben Login. Mein Problem ist also wirklich das Rumspazieren im Shop und das in den Warenkorb legen. Mehrfach-Login in diesem Sinne also - kein Ausspionieren/Beeinflussen des Warenkorbs von anderer Seite

... die Du alle in Deiner Datenbank speichern mußt ...

und die Wahrscheinlichkeit, dass ein anderer auf die Userdaten kommt
wird etwas größer.

Das sollte natürlich überhaupt nicht so ohne weiteres möglich sein.
Du kannst ja in die Session-ID auch Informationen mit hinein codieren,
die aus dem Verbindungsaufbau selbst stammen - sagen wir mal: Die IP-
Adresse des Client und/oder bestimmte HTTP-Header seines Browsers) -
und dies ebenfalls beim Decodieren der ID prüfen.

Na ja, das mit der IP-Adresse ist ja so eine Sache, ist ja nicht wirklich verlässlich. Noch ne blöde Frage von mir - codieren, decodieren - mit welchem "System" am Besten? md5() kann man ja nicht mehr decodieren (wenn ich nicht irre) - einen eigenen Algorithmus entwerfen oder gibt es hierzu Funktionen?

Das Hineinspringen in eine fremde Transaktion sollte schwieriger sein
als das Erraten Deines Session-ID-Algorithmus.

Ach ja - da sind wir ja schon - eigenen also. Hineinspringen wird schwieriger je mehr Infos ich vom User hineinpacken und kontrollieren kann - sehe ich das richtig nach deinen Ausführungen?

2. Irgendwie das beeinflussen was in der history-Liste steht - aber
   wie? (z.B. das eben diese eine Variable automatisch erneuert wird).

» Wenn ein Benutzer "zurück" will, dann will er zurück - die Frage ist,

wie gut Du die Session an derjenigen Stelle, wo er nun in eine andere
Richtung abbiegen will, sinnvollerweise weiter machen kannst.

Ja, hier habe ich mich auch etwas blöd ausgedrückt - ich will ihn auch nicht daran hindern zurück zu gehen. Ich dachte nur dass es eine Möglichkeit gibt, dass eben nicht meine Variable nicht fix in die History übernommen wird - ist aber nonsens. 2 fällt also aus.

Vielleicht brauchst Du wirklich in der Datenbank ein vollständiges
Protokoll aller HTTP-Requests des Benutzers, welche Du über die
Session-ID exakt erkennen kannst - dann kannst Du beim Eintreffen
eines Requests mit einer "alten" Session-ID alle Datenbankeinträge
mit "neueren" Session-IDs verwerfen und an der entsprechenden Stelle
weiter machen.

Mhh.... und was, wenn er dann wieder auf den Button Vorwärts klickt?

3. Bei Zurück eine automatische Meldung generieren (also wenn
   Timestamp nicht stimmt, die den Benutzer darauf hinweist, dass die
   Seite so nicht erreicht werden kann (meines Erachtens Gefahr der
   Verärgerung der Besucher)

Immer noch besser, als wenn der Benutzer andere Daten in seiner Shop-
Transaktion verarbeitet, als er selber glaubt.
Wenn der Kunde dann wegen eines fehlerhaften Shop-Systems einen Artikel
kauft, den er eigentlich durch "zurück" doch nicht haben wollte, wirst
Du nicht glücklich sein - denn dann ist der mal Kunde gewesen ...

Ja und das will ich vermeiden (no na ... - da schlägt der Österreicher durch :)).
Die Idee mit dem (nicht md5())-kodierten Timestamp hat mich ein ordentliches Stück weitergebracht, danke.
Nun drängt sich bei mir aber eine neue Frage auf und ich würde mich sehr über deine Meinung dazu freuen:
Ist es besser
a) Den User über SID + Timestamp durchzuführen (mit Abfrage <= bei Timestamp), in ID noch userspezifische Daten hinzuzufügen und das verbleibende Restrisiko zu schlucken (IP ist ja nicht sicher, kann also nur Daten einbinden, die auch ein anderer haben könnte)
b) Die einzelnen "abgelaufenen" Timestamps zusätzlich in der Datenbank zu speichern und so zusätzlich Abfragen/Erhöhung der Datenbankeinträge zu akzeptieren (Ladezeit, Performance?)

Danke für deine ausführliche Antwort und deine Ideen!!
lg
Sabine

Viele Grüße
      Michael

[Michael Schröpl]

Hi Sabine,

Ach ja - da sind wir ja schon - eigenen also.
Hineinspringen wird schwieriger je mehr Infos ich
vom User hineinpacken und kontrollieren kann - sehe
ich das richtig nach deinen Ausführungen?

Ja, auch - aber vor allem auch dann, wenn der Benutzer diese Informationen nicht so ohne weiteres fälschen kann (deshalb die HTTP-Header).

Wenn er "nur" eine Session-ID erraten muß, kann er einen normalen Browser nehmen - muß er auch noch konsistente Informationen erzeugen, dann muß er dafür ein Programm schreiben (oder installieren, falls irgend ein WebWasher so etwas bereits passend kann), welches den HTTP-Header explizit manipuliert.
Außerdem muß er, wenn er mehrere Hindernisse einzeln überwinden muß, erst mal von deren Existenz wissen ... wenn er beispielsweise die URLs auf Netz-Ebene oder durch einen Proxy-Server mit belauscht, wird er noch lange nicht in die Transaktion hinein springen können, falls diese URLs alleine über ihre eigene Konsistenz gar nicht genug aussagen.

Wenn dieses Programm dann auch noch mit Deinen womöglich JavaScript enthaltenden Seiten fertig werden muß, hast Du eine nette zusätzliche Hürde aufgebaut, die nicht mit brute force, sondern nur mit eigener Arbeit zu überwinden ist.

Jede Art der "Versicherung" lebt davon, sich den "Schadensfall" detailliert vorstellen zu können.
Das ist in Deinem Fall nicht anders: Je genauer Du weißt, wie ein Angreifer ungefähr arbeiten würde (und welche Information ihm dabei zur Verfügung steht), desto effektiver kannst Du ihm das Leben schwer machen.

Vielleicht brauchst Du wirklich in der Datenbank
ein vollständiges Protokoll aller HTTP-Requests
des Benutzers, welche Du über die Session-ID
exakt erkennen kannst - dann kannst Du beim
Eintreffen eines Requests mit einer "alten"
Session-ID alle Datenbankeinträge mit "neueren"
Session-IDs verwerfen und an der entsprechenden
Stelle weiter machen.
Mhh.... und was, wenn er dann wieder auf den Button
Vorwärts klickt?

Solange er noch nichts tut, was von dem bereits gespeicherten "Transaktions-Film" explizit abweicht, kannst Du seinen Timestamp als eine Art "Cursor" innerhalb dieses Films verwenden.

"Vor" und "Zurück" innerhalb der History verwenden jeweils nur Timestamps, die Du schon kennst.

Erst wenn er etwas tut, was einen neuen "Ereignis-Ast" aufmacht, wirst Du wohl oder übel den alten Ast absägen müssen ... es sei denn, Dein Transaktionslog ist ein Baum statt einer Liste ... dann müßte jeder Eintrag auch noch einen expliziten Vorgänger und Nachfolger haben, während bei einer Liste die sortierbaren Timestamps ausreichen. (Das wäre aber mehr, als der Browser selbst sinnvoll unterstützen würde - der kennt nur einen einzigen "Vorwärts"-Weg.)

Im Wesentlichen würdest Du also die Browser-History durch Navigation innerhalb Deines Transaktions-Logs serverseitig nachbilden - wobei Du dem Benutzer erlauben würdest, via URL mit timestamp an beliebige Stellen dieser History zu springen. (Er könnte ja auch eine bookmark verwendet haben oder was auch immer.)

Die Idee mit dem (nicht md5())-kodierten Timestamp
hat mich ein ordentliches Stück weitergebracht,
danke.
Nun drängt sich bei mir aber eine neue Frage auf
und ich würde mich sehr über deine Meinung dazu
freuen:
Ist es besser
a) Den User über SID + Timestamp durchzuführen
(mit Abfrage <= bei Timestamp), in ID noch
userspezifische Daten hinzuzufügen und das
verbleibende Restrisiko zu schlucken (IP ist ja
nicht sicher, kann also nur Daten einbinden, die
auch ein anderer haben könnte)

Je mehr Prüfsumme Du in die Session-ID mit einfügst, desto kleiner wird das Restrisiko.
Ich habe so etwas mal gebaut und den Timestamp selbst innerhalb der (decodierbaren) Session-ID gehalten ... da ich den Timestamp wieder extrahieren konnte, war ich beispielsweise auch in der Lage, diesen "veralten" zu lassen, also einen Zugriff nach mehr als <n> Sekunden nach Vergabe dieses time stamp abzuweisen (mit einer Meldung "sie haben mehr als <n> Sekunden keine Eingabe mehr vorgenommen - aus Sicherheitsgründen brechen wir Ihre Transaktion ab und führen Sie zurück zur Login-Seite" oder so ähnlich).
Je nachdem, welche Randbedingungen Deine Transaktion hat, wirst Du noch andere mehr oder weniger geeignete Konsistenz-Eigenschaften finden können.

b) Die einzelnen "abgelaufenen" Timestamps
zusätzlich in der Datenbank zu speichern und so
zusätzlich Abfragen/Erhöhung der Datenbankeinträge
zu akzeptieren (Ladezeit, Performance?)

Wenn Du den kompletten "Transaktionsfilm" speichern muß, damit Du an beliebigen Stellen aufsetzen kannst, brauchst Du ohnehin alle Timestamps - denn mit diesen erkennst Du ja die Position innerhalb des "Films" wieder.
Ist die Transaktion dagegen abgeschlossen (egal ob erfolgreich oder nicht), dann kannst Du Deine Infrastruktur (d. h. alle "Film-Einträge" mit dieser Session-ID) wieder abbauen, um die Tabelle aufzuräumen - für eine dauerhafte Archivierung brauchst Du zwar den Endzustand der Session, nicht aber deren Entstehungs-Historie.
Wobei Du den "Transaktionsfilm" möglicherweise in einer anderen Tabelle halten willst als das schlußendliche Protokoll der abgeschlossenen Transaktion - quasi in einem Cache innerhalb Deiner Datenbank, der nur die Einträge der laufenden Transaktionen enthält (so wie ein Rollback-Segment).

Viele Grüße
      Michael

[Sabine]

Hallo Michael!

Ach ja - da sind wir ja schon - eigenen also.
Hineinspringen wird schwieriger je mehr Infos ich
vom User hineinpacken und kontrollieren kann - sehe
ich das richtig nach deinen Ausführungen?

Ja, auch - aber vor allem auch dann, wenn der Benutzer diese Informationen nicht so ohne weiteres fälschen kann (deshalb die HTTP-Header).

Ist nachvollziehbar für mich. Welche Informationen des Users machen den Sinn um ihn zu unterscheiden? Wie gesagt bei der IP kann es ja sein, dass ich den Benutzer dann nicht mehr erkennen würde obwohl es der richtige ist. Ist es sinnvoll z.B. eine Kombination aus HTTP_USER_AGENT und HTTP_ACCEPT zu nehmen? Da ja (nach meinem bisherigen Wissenstand) eben die IP unsicher ist und auch der Referrer gefaked sein kann, drängt sich für mich die Frage auf - welche Informationen soll ich nehmen, die überhaupt Sinn machen um nicht etwas zu prüfen, dass mir eigentlich nichts bringt, weil 2 von 3 die gleichen Infos schicken.

Wenn dieses Programm dann auch noch mit Deinen womöglich JavaScript enthaltenden Seiten fertig werden muß, hast Du eine nette zusätzliche Hürde aufgebaut, die nicht mit brute force, sondern nur mit eigener Arbeit zu überwinden ist.

Warum JavaScript? In welcher Form kann mir hier Javascript etwas bringen? Das verstehe ich nicht - als einziges sehe ich hier eine Möglichkeit daran Besucher mit aktiviertem und deaktiviertem Javascript zu unterscheiden? Meinst du das oder bin ich hier am falschen Dampfer?

Solange er noch nichts tut, was von dem bereits gespeicherten "Transaktions-Film" explizit abweicht, kannst Du seinen Timestamp als eine Art "Cursor" innerhalb dieses Films verwenden.
"Vor" und "Zurück" innerhalb der History verwenden jeweils nur Timestamps, die Du schon kennst.
(Das wäre aber mehr, als der Browser selbst sinnvoll unterstützen würde - der kennt nur einen einzigen "Vorwärts"-Weg.)

Ach ja - ist klar, sobald er zurück geht und auf einen Link klickt ist die Möglichkeit wieder Vorwärts zu gehen ja weg. Dann kann ich also sobald er auf einen Link klickt den "Ast" absägen ...

Ich weiß (noch) nicht, ob sich das so programmieren lässt wie ich es mir denke, aber momentan habe ich folgendes im Kopf:
Sicherer kommt mir nach wie vor die Version vor, alle Schritte mitzuprotokollieren, denn dann ist der Zugriff des Besuchers nur Ok wenn er 5 Links mit 5 Timestamps geklickt hat, wenn er auf einen dieser zurückspringt und nicht nur wenn der Timestamp kleiner als der jetzige ist.
Nun könnte ich ja in der Datenbank die Timestamps eintragen, wenn er nun auf zurück geht, habe ich den Eintrag bereits da - ich weiß also dass er in der History zurückmaschiert ist, geht er auf vorwärts springt er zu seinem nächsten Datensatz in der DB. Klickt er aber auf einen Link, kommt ein neuer, noch nicht vorhandener Timestamp in der Datenbank und ich kann alle Einträge die größer sind als der Eintrag vor dem Klick auf den Link löschen. Sehe ich das richtig? Und noch eine abschließende Frage - sehr oft habe ich auf meine Idee mit den ändernden Timestamps die Meinung gehört, dass dies nicht sinnvoll wäre, aufgrund der vielen Einträge - Erhöhung der Ladezeiten, Datenbank-Overflow. Datenbank-Overflow mache ich mir weniger sorgen, da auch ich vorhabe, Einträge nach bestimmter Zeit zu löschen (z.b. wenn letzter Timestamp der SessionID länger als 1 Stunde von now, dann delete). Wie sieht es aber mit Ladezeiten aus? Kosten mich die Abfragen ob der Timestamp bereits vorhanden ist (evt. auch in einer Cache-Tabelle) und der Eintrag von neuen Timestamps viel Zeit oder ist dies vertretbar?

Danke für deine Antworten, Michael und ich würde mich freuen, wenn du dir noch einmal die Zeit nehmen würdest, meine verbleibenden Fragen zu beantworten.

Vielen lieben Dank und schöne Grüße
Sabine

Viele Grüße
      Michael

[Michael Schröpl]

Hallo Sabine,

Ja, auch - aber vor allem auch dann, wenn der Benutzer diese
Informationen nicht so ohne weiteres fälschen kann (deshalb
die HTTP-Header).
Ist nachvollziehbar für mich. Welche Informationen des Users machen
den Sinn um ihn zu unterscheiden? Wie gesagt bei der IP kann es ja
sein, dass ich den Benutzer dann nicht mehr erkennen würde obwohl
es der richtige ist. Ist es sinnvoll z.B. eine Kombination aus
HTTP_USER_AGENT und HTTP_ACCEPT zu nehmen?
Da ja (nach meinem bisherigen Wissenstand) eben die IP unsicher ist
und auch der Referrer gefaked sein kann, drängt sich für mich die
Frage auf - welche Informationen soll ich nehmen, die überhaupt Sinn
machen um nicht etwas zu prüfen, dass mir eigentlich nichts bringt,
weil 2 von 3 die gleichen Infos schicken.

Du hast schon ziemlich exakt erraten, was ich hier antworten will:
Je vielfältiger die Werte eines HTTP-Headers sind, desto besser eignet
er sich als zusätzliche Quelle der Konsistenz-Prüfung.
Ich würde in der Tat mit dem UserAgent anfangen - da ist die Chance,
daß ein Angreifer exakt denselben String sendet, schon ziemlich klein.
(Die Accept-Liste projeziert im Vergleich dazu deutlich schlechter.)

Wenn dieses Programm dann auch noch mit Deinen womöglich
JavaScript enthaltenden Seiten fertig werden muß, hast Du eine
nette zusätzliche Hürde aufgebaut, die nicht mit brute force,
sondern nur mit eigener Arbeit zu überwinden ist.
Warum JavaScript? In welcher Form kann mir hier Javascript etwas
bringen? Das verstehe ich nicht - als einziges sehe ich hier eine
Möglichkeit daran Besucher mit aktiviertem und deaktiviertem
Javascript zu unterscheiden? Meinst du das oder bin ich hier am
falschen Dampfer?

Wenn ich als Angreifer mit dem Erraten von URLs zwar Deine Session-ID
"brechen" kann, aber zusätzlich bestimmte Felder des HTTP-Headers auch
noch so senden muß, wie das der "belauschte" Browser tut, meiner aber
nicht kann, wäre meine nächste Idee, ein Programm wie meinen HTTP-
Tracer zu nehmen, also einen Roboter als HTTP-Client. Diesen so zu
schreiben, daß er HTTP bedienen kann, ist verhältnismäßig einfach -
wenn Deine Requests aber nur in einem Client korrekt funktionieren
würden, der JavaScript unterstützt, müßte ich einen kompletten Browser
schreiben!
Das soll nun keine Anregung sein, unbedingt JavaScript zu verwenden -
nur wenn Du das ohnehin schon tun würdest (wieso auch immer), wäre das
für den Angreifer eine zusätzliche Hürde, falls er nicht mit einem nor-
malen Browser angreifen kann, sondern einen "Eigenbau" braucht.

Sicherer kommt mir nach wie vor die Version vor, alle Schritte
mitzuprotokollieren, denn dann ist der Zugriff des Besuchers nur Ok
wenn er 5 Links mit 5 Timestamps geklickt hat, wenn er auf einen
dieser zurückspringt und nicht nur wenn der Timestamp kleiner als
der jetzige ist.
Nun könnte ich ja in der Datenbank die Timestamps eintragen, wenn er
nun auf zurück geht, habe ich den Eintrag bereits da - ich weiß also
dass er in der History zurückmaschiert ist, geht er auf vorwärts
springt er zu seinem nächsten Datensatz in der DB. Klickt er aber auf
einen Link, kommt ein neuer, noch nicht vorhandener Timestamp in der
Datenbank und ich kann alle Einträge die größer sind als der Eintrag
vor dem Klick auf den Link löschen. Sehe ich das richtig?

Genau das habe ich gemeint. Solange der innerhalb des Films nur bereits
bekannte Einträge abfährt, bleibt Dein Film erhalten. Wenn ein Request
kommt, kannst Du also prüfen, ob
a) Du den Timestamp schon in Deinem Film hast und
b) ob die dabei übertragenen Daten mit den in Deinem Film gespeicherten
   übereinstimmen.
Wenn der Kunde beispielsweise die Anzahl der Waren, die er in seinen
Warenkorb legt, nachträglich ändert, dann sendet er Dir den von Deinem
Shop gelieferten Timestamp zurück, aber abweichende Daten - nun ist es
Dein Job, diese als "anders" zu erkennen und ihm als Antwort eine neue
Seite mit neuem Timestamp zu senden ... hier beginnt der "neue Ast".
(Und genau in diesem Moment kannst Du den Film "kürzen", weil der Browser
es in seiner history genau jetzt ebenfalls tut.)

Und noch eine abschließende Frage - sehr oft habe ich auf meine Idee
mit den ändernden Timestamps die Meinung gehört, dass dies nicht
sinnvoll wäre, aufgrund der vielen Einträge - Erhöhung der Ladezeiten,
Datenbank-Overflow. Datenbank-Overflow mache ich mir weniger sorgen,
da auch ich vorhabe, Einträge nach bestimmter Zeit zu löschen (z.b.
wenn letzter Timestamp der SessionID länger als 1 Stunde von now,
dann delete).

Genauso gut kannst Du den Transaktionsfilm löschen, wenn die Transaktion
erfolgreich beendet oder explizit abgebrochen worden ist.
Das passiert innerhalb des RDBMS beim "commit": Die Änderungen an den
Tabellen werden festgeschrieben, und das Rollback-Segment wird vom
Ballast der Zwischenergebnisse befreit.

Das Ganze von einer zeitlichen Komponente abhängig zu machen ist m. E.
alleine nicht die beste Lösung. Denn Du willst diese Zeit einerseits
nicht so kurz machen, daß eine Zigarettenpause Deines Kunden die Session
abbricht, aber ansonsten so kurz wie möglich, um die Menge der Daten
so klein wie möglich zu halten.

Insofern wirst Du wahrscheinlich eine Mischung aus beidem haben wollen:
a) bei definierter Beendigung einer Transaktion sofort löschen.
b) periodisch alle veralteten Einträge (einige Stunden?) aufräumen.

Wie sieht es aber mit Ladezeiten aus? Kosten mich die Abfragen ob der
Timestamp bereits vorhanden ist (evt. auch in einer Cache-Tabelle)
und der Eintrag von neuen Timestamps viel Zeit oder ist dies
vertretbar?

Innerhalb der Transaktionsfilmtabelle liegt der Primärschlüssel auf dem
Paar aus Session-ID und Timestamp - damit bekommst Du sehr performant
exakte Treffer. Und wenn Du diese Transaktionsfilmtabelle von der
zusätzlich erforderlichen dauerhaften Aufbewahrung der Transaktionen
(um dem Kunden später nachweisen zu können, wann er was gekauft hat)
trennst, hast Du
a) eine große Archiv-Tabelle, die selten geändert wird und
b) eine kleine Film-Tabelle, die ständig geändert wird.

Da diese kleine Tabelle immer mal wieder komplett leer wird, ist es
nicht schlimm, daß sie ständig geändert wird - zwar degeneriert der
Index erheblich, aber er wird ja auch immer mal wieder komplett
abgebaut.
Bei jeder Änderung des Tabelleninhalts muß der Primärschlüsselindex
mitgepflegt werden - das ist aber nicht ungewöhnlich aufwändig.

Wie ich schon zweimal erwähnt habe, würde diese Filmtabelle in etwa
das nachbilden, was eine Datenbank mit einem Rollback-Segment tut.
(Während das Transaktions-Archiv Deines Shops dann in etwa der eigent-
lichen Tabelle entspricht.)
Und so, wie eine Datenbank auf ihr eigenes Rollback-Segment performanter
zugreifen kann als auf eine echte Tabelle, könntest auch Du versuchen,
die Filmtabelle (kleiner, aber mit viel mehr Änderungen als das Archiv)
in einem performanteren Modus laufen zu lassen.
Vielleicht läßt sich diese Tabelle ja komplett im Hauptspeicher halten?
(Das wäre ein Tuning-Job für den DB-Administrator.)

Viele Grüße
      Michael

P.S.: Deine Fragestellungen tendieren dazu, interessant zu sein. :-)

[Sabine]

Hallo Michael!

Ich würde in der Tat mit dem UserAgent anfangen - da ist die Chance,
daß ein Angreifer exakt denselben String sendet, schon ziemlich klein.
(Die Accept-Liste projeziert im Vergleich dazu deutlich schlechter.)

Ok, danke für die Info, da habe ich ja schon mal nen Anfang.

wäre meine nächste Idee, ein Programm wie meinen HTTP-
Tracer zu nehmen, also einen Roboter als HTTP-Client. Diesen so zu
schreiben, daß er HTTP bedienen kann, ist verhältnismäßig einfach -

Puh, das wusste ich nicht.

wenn Deine Requests aber nur in einem Client korrekt funktionieren
würden, der JavaScript unterstützt, müßte ich einen kompletten Browser
schreiben!

Aha! Jetzt verstehe ich den Sinn, wenn dies auch komplettes Neuland für mich ist.

Das soll nun keine Anregung sein, unbedingt JavaScript zu verwenden -
nur wenn Du das ohnehin schon tun würdest (wieso auch immer), wäre das
für den Angreifer eine zusätzliche Hürde, falls er nicht mit einem nor-
malen Browser angreifen kann, sondern einen "Eigenbau" braucht.

Ich verwende zwar Javascript (Mouseover-Grafiken), allerdings funktioniert die Seite auch ohne Javascript. Hilft mir das dann was, weil ich dann vom HTTP-Tracer verlange sich irgendwie zu deklarieren - also ich verwende Javascript oder ich verwende es nicht?

Wenn der Kunde beispielsweise die Anzahl der Waren, die er in seinen
Warenkorb legt, nachträglich ändert, dann sendet er Dir den von Deinem
Shop gelieferten Timestamp zurück, aber abweichende Daten - nun ist es
Dein Job, diese als "anders" zu erkennen und ihm als Antwort eine neue
Seite mit neuem Timestamp zu senden ... hier beginnt der "neue Ast".

Ist klar - um mal kurz meine Gedanken zusammenzufassen, ein Beispiel meinerseits mit dem was dabei in der Datenbank passiert.
1. Mein Besucher surft auf meiner Website herum
2. Er führt irgendeine Aktion aus, klickt auf einen Link, einen Submit-Button oder geht z.B. Back.
3. Ich überprüfe, ob ich die Kombination Timestamp + SessionID von ihm habe
4. Ich überprüfe, ob die SessionID seine sein kann (z.B. User-Agent)
5. Wenn es um den Warenkorb geht überprüfe ich zusätzlich ob er einen bestehenden Eintrag des Warenkorbs verändert hat
6. Wenn die Prüfungen alle Ok waren, darf er weiter
Zusätzlich kommt dann aber noch mein Löschen dazu, ich habe vereinfacht folgende Filmtabelle

UserID           timestamp
xx               1
xx               2
xx               3
xx               4

Wenn jetzt der User z.B. zurückgegangen ist auf timestamp 1 generiere ich 1. einen neuen Datenbankeintrag (timestamp 5), den ich grundsätzlich als nächstes von ihm erwarte (wenn er auf einen Link klickt). Wenn er das dann auch tut, lösche ich alle Einträge die größer sind als der timestamp den er gerade aufgerufen hat bis auf den letzten Eintrag.

Genauso gut kannst Du den Transaktionsfilm löschen, wenn die Transaktion
erfolgreich beendet oder explizit abgebrochen worden ist.
Insofern wirst Du wahrscheinlich eine Mischung aus beidem haben wollen:
a) bei definierter Beendigung einer Transaktion sofort löschen.
b) periodisch alle veralteten Einträge (einige Stunden?) aufräumen.

Erfolgreich beendet ist mir klar - er hat die Bestellung abgeschlossen, ich lösche den Transaktionsfilm, lasse den Haupteintrag in einer Tabelle in der ich in irgendeine Form den jeweiligen Kunden mit der Bestellung in Verbindung bringe. Springt er dann weiter, verpasse ich ihm eine neue SessionID und starte das Spiel von vorne.
Bei explizit abgebrochen komme ich nun nicht ganz klar

a) Wenn er aussteigt (also die Seite verlässt) kann ich das nicht feststellen - hier käme dann Variante b) - dein Eintrag unten, nach einigen Stunden aufräumen - zum Tragen.
b) Wenn er den Warenkorb löscht - Ok ist mir klar, dann kann ich die Transaktionen löschen und ihn von vorne beginnen lassen
c) Wenn er im Bestellvorgang abbricht - denke ich sollte ich wohl die Transaktion noch nicht beendigen, oder? Meinem Besucher ist vielleicht grad eingefallen, dass er doch noch was bestellen oder etwas aus dem Warenkorb entfernen möchte und er geht nochmal zurück, dann sollte ich ihm aber wohl sinnvollerweise seine Daten noch erhalten.

Wie sieht es aber mit Ladezeiten aus? Kosten mich die Abfragen ob der
Timestamp bereits vorhanden ist (evt. auch in einer Cache-Tabelle)
und der Eintrag von neuen Timestamps viel Zeit oder ist dies
vertretbar?

Da diese kleine Tabelle immer mal wieder komplett leer wird, ist es
nicht schlimm, daß sie ständig geändert wird - zwar degeneriert der
Index erheblich, aber er wird ja auch immer mal wieder komplett
abgebaut.
Bei jeder Änderung des Tabelleninhalts muß der Primärschlüsselindex
mitgepflegt werden - das ist aber nicht ungewöhnlich aufwändig.

Ok, dankeschön für die Info. Das beruhigt mich. Nach vielen Antworten dachte ich wirklich schon was mir heute jemand geschrieben hat, dass ich ein Sicherheitsfanatiker bin und womöglich mit Kanonen auf Spatzen schieße.

Und so, wie eine Datenbank auf ihr eigenes Rollback-Segment performanter
zugreifen kann als auf eine echte Tabelle, könntest auch Du versuchen,
die Filmtabelle (kleiner, aber mit viel mehr Änderungen als das Archiv)
in einem performanteren Modus laufen zu lassen.
Vielleicht läßt sich diese Tabelle ja komplett im Hauptspeicher halten?
(Das wäre ein Tuning-Job für den DB-Administrator.)

Das wird nicht gehen, da ich hierauf keinen Zugriff habe (externer Server). Habe ich als "normaler Besitzer" einer DB bei einem Fremdhoster die Möglichkeit die Filmtabelle in einem performanteren Modus laufen zu lassen? Wenn ja, kannst du mir vielleicht ein Stichwort dazu geben, womit ich mich hier beschäftigen sollte?

Abschließend habe ich (wie könnte es auch anders sein) noch eine Frage - ich verspreche es, jetzt hast du dann bald Ruhe von mir, aber ich freue mich total, endlich mit jemanden darüber "diskutieren" (bzw. jemanden dazu löchern :)) zu können, was schon die ganze Zeit in meinem Gehirn herumbraust.

Wenn mein Besucher nun beschließt das zu bestellen, was er in den Warenkorb gelegt hat,
a) registriert er sich, wenn er ein neuer Kunde ist
b) loggt sich ein, wenn er ein bestehender Kunde ist

soweit alles klar, er kann aber jederzeit wieder aus dem Bestellvorgang rausgehen - ist es dann empfehlenswert ihn aus Sicherheitsgründen, wenn er dann doch wieder bestellen will, nochmals einloggen zu lassen oder ihn als eingeloggt gespeichert lassen. Was ist größer, die Gefahr ihn zu verärgern wenn er wieder einloggen muss oder das Risiko einen Fremdangriff - dann allerdings in einen kritischeren Bereich aufgrund seiner personenbezogenen Daten zu haben?

Danke im Voraus und im Nachhinein für all deine Antworten und deine Mühe.

Schöne Grüße
Sabine

Viele Grüße
      Michael

P.S.: Deine Fragestellungen tendieren dazu, interessant zu sein. :-)

Dankeschön, deine Antworten aber nicht minder!!

[Michael Schröpl]

Hallo Sabine,

wäre meine nächste Idee, ein Programm wie meinen
HTTP-Tracer zu nehmen, also einen Roboter als
HTTP-Client. Diesen so zu schreiben, daß er HTTP
bedienen kann, ist verhältnismäßig einfach -
Puh, das wusste ich nicht.

Nimm Dir mal
   http://www.schroepl.net/cgi-bin/http_trace.pl
als Beispiel - das Ding reicht Deine HTTP-Requests
einfach nur durch, aber es wäre trivial, definierte
Änderungen am HTTP-Header durchzuführen, also
beispielsweise den UserAgent zu fälschen.

Ich verwende zwar Javascript (Mouseover-Grafiken),
allerdings funktioniert die Seite auch ohne
Javascript.
Hilft mir das dann was, weil ich dann vom HTTP-
Tracer verlange sich irgendwie zu deklarieren -
also ich verwende Javascript oder ich verwende es
nicht?

Nein. Wenn Du JavaScript nur für "nice to have"
verwendest, wird der Robot problemlos "korrekte"
HTTP-Requests erzeugen können.
Würdest Du beispielsweise mit JavaScript URL-Teile
in Links bzw. Formularen manipulieren, dann sähe das
anders aus.

Frage Dich einfach mal, ob ein Links-Checker durch Deinen Shop-Dialog hindurchlaufen könnte oder nicht.

1. Mein Besucher surft auf meiner Website herum
2. Er führt irgendeine Aktion aus, klickt auf einen
      Link, einen Submit-Button oder geht z.B. Back.
3. Ich überprüfe, ob ich die Kombination Timestamp
      + SessionID von ihm habe
4. Ich überprüfe, ob die SessionID seine sein kann
      (z.B. User-Agent)
5. Wenn es um den Warenkorb geht überprüfe ich
      zusätzlich ob er einen bestehenden Eintrag des
      Warenkorbs verändert hat
6. Wenn die Prüfungen alle Ok waren, darf er weiter

Wobei er als Antwort eine Seite bekommt, die eventuell
einen bereits vorhandenen timestamp haben kann -
nämlich genau dann, wenn der empfangene timestamp im
Film gefunden wurden und Test Nr. 5 ebenfalls positiv
ausfiel.
Andernfalls (Test 5 negativ) bekommt er eben eine neue
Seite mit einem neuen Timestamp, und der alte Film wird
ab dieser Stelle gelöscht.

Wenn jetzt der User z.B. zurückgegangen ist auf
timestamp 1 generiere ich 1. einen neuen
Datenbankeintrag (timestamp 5), den ich
grundsätzlich als nächstes von ihm erwarte
(wenn er auf einen Link klickt).

Warum schon jetzt?

Wenn er zurück gegangen ist auf timestamp 1, wirst
Du ihm eine Seite mit timestamp 2 senden wollen.
Er soll ja innerhalb des existierenden Films vor und
zurück blättern können - und eventuell auch wieder
vorwärts springen.
Wenn er den Inhalt des dabei gesendeten Formulars
tatsächlich ändert, dann wirst Du das bei Test 5
nach dem Empfang der Seite mit Timestamp 2 merken.

Bei explizit abgebrochen komme ich nun nicht ganz
klar

Es könnte ja sein, daß Du in jeder Seite einen Button
"gesamte Aktion abbrechen" drin hast.
Du hast zwar keine Garantie, daß der Benutzer diesen
Button wirklich betätigt, aber Du kannst ihm die
Gelegenheit dazu ja wenigstens mal geben.

Bei Online-Banking gilt manchmal als zusätzliche
Sicherheitsmaßnahme, daß mehrfaches gleichzeitiges
login nicht möglich ist. Wenn ein Anwender seinen
Browser schließt, ohne sich abzumelden, und sich
sofort wieder anmelden will, kommt es bei bestimmten
Banken vor, daß diese eine Anmeldung für eine bestimmte
timeout-Phase sperren - um beispielsweise das
Durchprobieren von Passworten zu verhindern oder
Ähnliches.
In Deinem Fall könntest Du etwas Ähnliches einbauen
wollen - beispielsweise die Kombination aus IP-Adresse
und UserAgent (oder was auch immer) eine bestimmte Zeit
lang sperren, nachdem eine Transaktion mit diesen Daten
offensichtlich "kaputt gegangen" ist, und das mit einer
erklärenden Meldung an den Anwender. Dieser lernt auf
diese Weise, daß es auch in seinem eigenen Interesse
ist, sich ordentlich abzumelden ...

b) Wenn er den Warenkorb löscht - Ok ist mir klar,
dann kann ich die Transaktionen löschen und ihn von
vorne beginnen lassen

Yep - auch das ist ein Fall, in dem Du den Film früher
los wirst als nach Deinem timeout.
Jede Chance, diese Datenmenge frühzeitig zu reduzieren,
darfst Du gerne mitnehmen.

c) Wenn er im Bestellvorgang abbricht - denke ich
sollte ich wohl die Transaktion noch nicht
beendigen, oder? Meinem Besucher ist vielleicht grad
eingefallen, dass er doch noch was bestellen oder
etwas aus dem Warenkorb entfernen möchte und er geht
nochmal zurück, dann sollte ich ihm aber wohl
sinnvollerweise seine Daten noch erhalten.

Um das zu beurteilen, weiß ich nicht genug über den
genauen Dialog - das mußt Du selbst entscheiden.

Ok, dankeschön für die Info. Das beruhigt mich.
Nach vielen Antworten dachte ich wirklich schon
was mir heute jemand geschrieben hat, dass ich ein
Sicherheitsfanatiker bin und womöglich mit Kanonen
auf Spatzen schieße.

Der Sinn dieser Diskussion ist doch gerade, zu
erkennen, welche Maßnahmen welches Preis-/Leistungs-
Verhältnis mit sich bringen.
Da ist es eine gute Ausgangssituation, erst mal hyper-
mißtrauisch zu sein - besser jedenfalls als zu leichtsinnig ... was von alledem Du später tatsächlich
realisieren wirst, dürfte nicht zuletzt davon abhängen,
was Dein Auftraggeber zu bezahlen bereit ist. ;-)

Vielleicht läßt sich diese Tabelle ja komplett
im Hauptspeicher halten?
(Das wäre ein Tuning-Job für den DB-
Administrator.)
Das wird nicht gehen, da ich hierauf keinen Zugriff
habe (externer Server). Habe ich als "normaler
Besitzer" einer DB bei einem Fremdhoster die
Möglichkeit die Filmtabelle in einem performanteren
Modus laufen zu lassen? Wenn ja, kannst du mir
vielleicht ein Stichwort dazu geben, womit ich mich
hier beschäftigen sollte?

Bei mySQL ist das beispielsweise schon eine Eigenschaft
des verwendeten Tabellentyps.

Was genau Du an Einflußnahme hast, ist natürlich
abhängig von Deinem Provider - aber Du kannst Deinem
Auftraggeber gegenüber auf jeden Fall mal erwähnen,
daß diese beiden Tabellen(Film und Archiv) erheblich
unterschiedliche Änderungsraten haben werden, so daß
sich eine unterschiedliche Behandlung innerhalb des
RDMBS lohnen könnte.
Sollte dann später ein Lastproblem entstehen, weißt Du
wenigstens, wo man ansetzen könnte - falls nicht, war
es halt eine Information mehr, die an anderer Stelle
vielleicht mal etwas helfen kann.

Abschließend habe ich (wie könnte es auch anders
sein) noch eine Frage - ich verspreche es, jetzt
hast du dann bald Ruhe von mir,

Tststs ... ;-)

aber ich freue mich total, endlich mit jemanden
darüber "diskutieren" (bzw. jemanden dazu löchern
:)) zu können, was schon die ganze Zeit in meinem
Gehirn herumbraust.

Ich doch auch - verglichen mit den diversen 2-Frames-Fragen oder den verzweifelten Versuchen, dem Anwender
seinen Browser zu verstümmeln, ist dieser Thread eine
erfreuliche Abwechslung!

Wenn mein Besucher nun beschließt das zu bestellen,
was er in den Warenkorb gelegt hat,
a) registriert er sich, wenn er ein neuer Kunde ist
b) loggt sich ein, wenn er ein bestehender Kunde ist
soweit alles klar, er kann aber jederzeit wieder aus
dem Bestellvorgang rausgehen - ist es dann
empfehlenswert ihn aus Sicherheitsgründen, wenn er
dann doch wieder bestellen will, nochmals einloggen
zu lassen oder ihn als eingeloggt gespeichert
lassen.

Wie genau steht das zu verwendende Verfahren zum
Einloggen bereits fest?
Deine Frage zielt auf Usability; ich kann an dieser
Stelle nicht für Deine Kunden sprechen, sondern
höchstens kommentieren, mit welchem Verfahren Du
welche Freiheitsgrade hättest.

Was ist größer, die Gefahr ihn zu verärgern wenn
er wieder einloggen muss oder das Risiko einen
Fremdangriff - dann allerdings in einen kritischeren
Bereich aufgrund seiner personenbezogenen Daten zu
haben?

Wenn Du ein Login-Verfahren verwenden kannst, das auch
beim Zurück-Gehen erhalten bleibt (Server Authentica-
tion bzw. Cookie), besteht das Problem gar nicht.

Wenn die Authentifizierung aber Bestandteil Deiner
Session-ID ist, also im Query-String Deiner URLs
steckt, dann ist ein Schritt zurück und ein neuer
Anlauf in Richtung erfolgreichem Abschluß der Trans-
aktion eine echte Zeitreise, bei der Deine Links das
Wissen um die (zeitlich später liegende) Anmeldung
verloren haben - da dürftest Du einfach keine Chance
haben.

Vielleicht kannst Du Deine Stammkunden ermutigen,
sich bereits zu Beginn der Transaktion anzumelden -
beispielsweise dadurch, daß angemeldete Besucher
irgendwelche Zusatz-Features während des Dialogs
bekommen?

Dein "Kunden-Gedächtnis" könnte beispielsweise die
Information besitzen, was dieser Kunde bisher schon
alles gekauft hat, und ihn auf aktuelle Angebote
vergleichbarer Produkte hinweisen ... ungefähr das,
was viele Webseiten mit Cookies probieren.

Oder vielleicht kann ein angemeldeter Besucher
dauerhafte irgendwelche Konfigurationen vornehmen,
beispielsweise eine bestimmte, ihm genehme Dar-
stellungsform der Dialogführung, so daß die Seiten
bei jedem Kunden dessen Vorlieben entsprechend
aussehen?
Wenn Deine Kunden sich etwas davon versprechen
können, sich präventiv angemeldet zu haben, dann
tun sie das auch - wenigstens einige von ihnen.

Viele Grüße
      Michael

[Sabine]

Hallo Michael!

Nimm Dir mal
   http://www.schroepl.net/cgi-bin/http_trace.pl
als Beispiel - das Ding reicht Deine HTTP-Requests
einfach nur durch, aber es wäre trivial, definierte
Änderungen am HTTP-Header durchzuführen, also
beispielsweise den UserAgent zu fälschen.

Wahnsinn - bis dato war ich doch wirklich so naiv anzunehmen, das ich darauf vertrauen kann, ausser ich habe einen Opera-Besucher der sich anders ausgibt. Man lernt wirklich nie aus!

Nein. Wenn Du JavaScript nur für "nice to have"
verwendest, wird der Robot problemlos "korrekte"
HTTP-Requests erzeugen können.
Würdest Du beispielsweise mit JavaScript URL-Teile
in Links bzw. Formularen manipulieren, dann sähe das
anders aus.

Frage Dich einfach mal, ob ein Links-Checker durch Deinen Shop-Dialog hindurchlaufen könnte oder nicht.

Ja, könnte er. Dann fällt das weg für mich, da ich auch Besucher mit deaktivertem JavaScript nicht ausschließen möchte.

5. Wenn es um den Warenkorb geht überprüfe ich
      zusätzlich ob er einen bestehenden Eintrag des
      Warenkorbs verändert hat
6. Wenn die Prüfungen alle Ok waren, darf er weiter

Andernfalls (Test 5 negativ) bekommt er eben eine neue
Seite mit einem neuen Timestamp, und der alte Film wird
ab dieser Stelle gelöscht.

Wenn jetzt der User z.B. zurückgegangen ist auf
timestamp 1 generiere ich 1. einen neuen
Datenbankeintrag (timestamp 5), den ich
grundsätzlich als nächstes von ihm erwarte
(wenn er auf einen Link klickt).

Warum schon jetzt?

Wenn er zurück gegangen ist auf timestamp 1, wirst
Du ihm eine Seite mit timestamp 2 senden wollen.
Er soll ja innerhalb des existierenden Films vor und
zurück blättern können - und eventuell auch wieder
vorwärts springen.
Wenn er den Inhalt des dabei gesendeten Formulars
tatsächlich ändert, dann wirst Du das bei Test 5
nach dem Empfang der Seite mit Timestamp 2 merken.

Jetzt dachte ich gerade wir sprechen doch von etwas ganz verschiedenem, aber ich denke so ist es gar nicht.
Ich dachte daran, den Film nur dann zu löschen, wenn er einmal zurückgeht und dann aber einen anderen Link anklickt als den, den ich von ihm grundsätzlich erwarte (also den letzten Eintrag in der Filmtabelle) - meine Basisüberlegung waren dabei andere Seiten als direkt der Warenkorb.

Im Prinzip ist es beim Warenkorb nichts anderes, den hier breche ich meinen Film ja genauso ab, wenn er z.B. die Menge einer Warenkorbposition ändert, als wenn ich auf einer anderen Seiten auf einen Link klicke.

Der Besucher nimmt sich dabei selbst die Möglichkeit die Seiten die er über den Back-Button zurückgesprungen ist über Vorwärts wieder aufzurufen und wenn das der Fall ist kann ich Einträge der Filmtabelle löschen. So nur mal meine theoretischen Gedanken, ich werde mich jetzt einmal ans Programmieren machen, um zu sehen ob meine theoretischen Vorstellungen in der Praxis auch so laufen, wie ich es mir denke.

Bei explizit abgebrochen komme ich nun nicht ganz
klar

Es könnte ja sein, daß Du in jeder Seite einen Button
"gesamte Aktion abbrechen" drin hast.
Du hast zwar keine Garantie, daß der Benutzer diesen
Button wirklich betätigt, aber Du kannst ihm die
Gelegenheit dazu ja wenigstens mal geben.

Bei Online-Banking gilt manchmal als zusätzliche
Sicherheitsmaßnahme, daß mehrfaches gleichzeitiges
login nicht möglich ist. Dieser lernt auf
diese Weise, daß es auch in seinem eigenen Interesse
ist, sich ordentlich abzumelden ...

Ist klar, dies ist aber fürs erste nicht vorgesehen. Der Kunde hat (siehe b) natürlich die Möglichkeit den Warenkorb ganz zu entleeren. Mein Kunde will ihm aber zusätzlich nicht die Möglichkeit "aufs Aug drücken" jederzeit abbrechen zu können.

b) Wenn er den Warenkorb löscht -
Yep - auch das ist ein Fall, in dem Du den Film früher
los wirst als nach Deinem timeout.
Jede Chance, diese Datenmenge frühzeitig zu reduzieren,
darfst Du gerne mitnehmen.

Ok, soweit verstanden.

c) Wenn er im Bestellvorgang abbricht - denke ich
sollte ich wohl die Transaktion noch nicht
beendigen, oder? Um das zu beurteilen, weiß ich nicht genug über den
genauen Dialog - das mußt Du selbst entscheiden.

Ja, Ok. Für mich ist es sinnvoller ihm dann seine Daten zu lassen.

Der Sinn dieser Diskussion ist doch gerade, zu
erkennen, welche Maßnahmen welches Preis-/Leistungs-
Verhältnis mit sich bringen.
Da ist es eine gute Ausgangssituation, erst mal hyper-
mißtrauisch zu sein - besser jedenfalls als zu leichtsinnig ... was von alledem Du später tatsächlich
realisieren wirst, dürfte nicht zuletzt davon abhängen,
was Dein Auftraggeber zu bezahlen bereit ist. ;-)

Das ist klar. Ich sehe das Ganze für mich auch als Diskussion für die Zukunft, auch wenn ich alles was ich durch deine Unterstützung nun dazugelernt habe, vielleicht nicht im aktuellen Projekt umsetzen werde können, obwohl dies sicherlich zu einem großen Teil der Fall sein wird, da auch meinem Auftraggeber die Sicherheit sehr wichtig ist.

Mir ist es einfach wichtig, mich weiterzuentwickeln, für mich die Möglichkeiten und Grenzen abstecken zu können und mir Gedanken darüber zu machen, was ist unabdingbar, was ist möglich und was nicht. Denn nur so kann ich meiner Meinung nach kompetent beraten und argumentieren. Für mich ist das sehr wichtig - nicht nur beim Thema Sicherheit sondern allgemein bei meiner Arbeit. Wenn ich das nicht tun würde, denke ich mir, kann ich mich gleich der Gemeinde der "Frontpage-Webdesigner" anschließen :).

Möglichkeit die Filmtabelle in einem performanteren
Modus laufen zu lassen? Wenn ja, kannst du mir
vielleicht ein Stichwort dazu geben, womit ich mich
hier beschäftigen sollte?

Bei mySQL ist das beispielsweise schon eine Eigenschaft
des verwendeten Tabellentyps.

Ach ja, dann wäre hier wohl beispielsweise eine HEAP-Tabelle zu empfehlen ...

Abschließend habe ich (wie könnte es auch anders
sein) noch eine Frage - ich verspreche es, jetzt
hast du dann bald Ruhe von mir,

Tststs ... ;-)

Ich würds auch nicht glauben an deiner Stelle :)

aber ich freue mich total, endlich mit jemanden
darüber "diskutieren" (bzw. jemanden dazu löchern
:)) zu können, was schon die ganze Zeit in meinem
Gehirn herumbraust.

Ich doch auch - verglichen mit den diversen 2-Frames-Fragen oder den verzweifelten Versuchen, dem Anwender
seinen Browser zu verstümmeln, ist dieser Thread eine
erfreuliche Abwechslung!

Freut mich, dass du das so siehst.

Wie genau steht das zu verwendende Verfahren zum
Einloggen bereits fest?
Deine Frage zielt auf Usability; ich kann an dieser
Stelle nicht für Deine Kunden sprechen, sondern
höchstens kommentieren, mit welchem Verfahren Du
welche Freiheitsgrade hättest.

Wenn Du ein Login-Verfahren verwenden kannst, das auch
beim Zurück-Gehen erhalten bleibt (Server Authentica-
tion bzw. Cookie), besteht das Problem gar nicht.

Ist klar.

Wenn die Authentifizierung aber Bestandteil Deiner
Session-ID ist, also im Query-String Deiner URLs
steckt, dann ist ein Schritt zurück und ein neuer
Anlauf in Richtung erfolgreichem Abschluß der Trans-
aktion eine echte Zeitreise, bei der Deine Links das
Wissen um die (zeitlich später liegende) Anmeldung
verloren haben - da dürftest Du einfach keine Chance
haben.

Ist eigentlich logisch. Das hat meine Gehirnwindungen wieder etwas entwirrt ...

Vielleicht kannst Du Deine Stammkunden ermutigen,
sich bereits zu Beginn der Transaktion anzumelden -
beispielsweise dadurch, daß angemeldete Besucher
irgendwelche Zusatz-Features während des Dialogs
bekommen?
Wenn Deine Kunden sich etwas davon versprechen
können, sich präventiv angemeldet zu haben, dann
tun sie das auch - wenigstens einige von ihnen.

Ja, da hast du Recht. Auf so etwas in der Richtung habe ich auch schon gedacht. Mal schauen, was mein Auftraggeber dazu sagt.

Lieber Michael, ich danke dir sehr für deine Anregungen, Tipps und deine Hilfe. Ich werde nun mal mein dank dir neu erworbenes Wissen in die Praxis umsetzen.

Danke, liebe Grüße und viel Erfolg bei deiner Arbeit!
Sabine

Viele Grüße
      Michael