Usertracking, history.back, reload

[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!!