• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

Site-Parsing überprüfen ?

Ob die Session noch gültig ist solltest du aber auf dem Server speichern und nicht im Cookie oder anderswo auf dem Client.
 
Tu ich ja, Korbinian. Der Client übermittelt im Request sowieso immer die Session-ID. Die prüfe ich am Server auf Gültigkeit. Wenn abgelaufen, Tschüss.
Und wenn Cookies aktiviert sind, prüfe ich serverseitig sowohl, ob die Session-ID aus dem Request mit der Session-ID im Cookie überein stimmt und auch ob diese Session noch läuft.
 
Hmm .. klingt alles sehr nach dem, was ich suche, was bei mir fehlt und es anscheinend so einfach macht sich die Daten auslesen zu lassen. Von der Theorie hab ich es verstanden .. kennt zufällig jemand einen Link wo man auch bei praktischen Umsetzung ein wenig an die Hand genommen wird und das Ganze Laienhaft erklärt wird? Mir ist nämlich absolut nicht klar WO ich die Session-ID's generiere, WO ich irgendwas in der Datenbank hin speichern soll und WAS ich letztendlich AN WELCHER STELLE miteinander vergleichen muss um zu merken, ob eine Session abgelaufen ist oder nicht. Google liefert mir leider nur Ergebnisse dass es einfach sein soll das umsetzen und wie die Theorie aussieht.

lg und vielen Dank
 
Xoli, man kann das ganz einfach machen. Beim Login erzeugt man eine Zufallszahl und schaut in der Tabelle, ob die eindeutig ist oder ob es sie schon gibt oder gab. Falls nicht, neue erzeugen, bis Eindeutigkeit entsteht.
Diese Zufallszahl versieht man mit Timestamp und speichert sie in der Tabelle am besten gleich zusammen mit den Berechtigungen für diese Session.
Im Client Code (also HTML/JS etc.) schaut man, dass bei ALLEN Requests ein hidden Feld ergänzt wird, dass diese ID liefert. Dazu schickt man dem Client beim Login ein Cookie in dem ebenfalls diese ID drin ist.
So, war es schon. Setzt natürlich voraus, dass sämtliche Seiten dynmisch durch ein Serverscript geparst oder erzeugt werden. Mit statischen Seiten ist das ein bisschen schwieriger.

Ab sofort brauchst du serverseitig bei jedem Request einfach nur das Cookie auslesen, mit der ID aus dem hidden Feld vergleichen und danach in der Tabelle schauen, ob der Timestamp dieser ID plus die erlaubte Sessiondauer überschritten ist oder nicht.
Wenn nicht überschritten, einfach Timestamp auf aktuelle Zeit setzen, das ist dann die Session Verlängerung oder wenn überschritten Session löschen, Fehler an Client geben.
Das wars.
 
Zuletzt bearbeitet:
Man kann das z.B. so ähnlich machen, dann verhindert man das Problem, das bereits ein gleicher String existieren kann:
PHP:
$einzigartiger_benutzerstring = md5($_POST['benutzername'].rand());
$uhrzeit = (microtime(true)
$prefix = md5(rand());
$zufalls_string = uniqid($prefix, true);

$teil1 = $einzigartiger_benutzerstring.$uhrzeit.$prefix.$zufalls_string;
$teil1 = md5($teil1);

$zeichen_zur_auswahl = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!=:().#";
$lang = 50;
$string = "";
for ($x=0; $x<$lang; $x++) {
       $string .= $zeichen_zur_auswahl[rand(0,strlen($zeichen_zur_auswahl)-1)];
}
$teil2 = md5($string);

$hash = $teil1.$teil2;
$hash = hash('sha512', $hash);

$gesamt = $hash.$string;
$gesamt = substr($gesamt, 0, 150);
$gesamt = hash('sha512', $gesamt);
$session = substr($gesamt, 0, 50);
echo $session; //gibt 50 Zeichen langen, wirklich eindeutigen String aus

Ich weiß, dass md5 mittlerweile als unsicher gilt, aber durch das immer neue weitere Verschachteln, Hashen, und Hinzufügen von Strings erzeugt man durch eine Methode wie oben eine unter keinen Umständen nachvollziehbare Zufallszahl.
 
durch das immer neue weitere Verschachteln, Hashen, und Hinzufügen von Strings erzeugt man durch eine Methode wie oben eine unter keinen Umständen nachvollziehbare Zufallszahl.
Richtig. Und selbst wenn man eine Zufallszahl nachvollziehen könnte, die der Server auch zu dieser Zeit generieren würde müsste ja mit dieser Zahl eine Session auch gerade laufen. Das weiß der Angreifer ja garnicht, wann zu dieser Zeit mit dieser Nummer eine Session läuft. Und selbst wenn auch das gelingen würde müsste es genau der richtige User mit genau den benötigten Rechten sein dem diese ID zugeordnet wird und nicht irgendeiner.
 
eine unter keinen Umständen nachvollziehbare Zufallszahl
das würde ich so nicht unterschreiben... zu dem Thema: DEFCON 18: How I Met Your Girlfriend 1/3 - YouTube ist zwar schon ein bisschen älter, aber immer noch interessant, wie man die Entropie veringern kann. Ich denke, das kann man bei dir auch.

PS: Und durch Hashen erzeugt man keine Entropie.
PPS: und auch bei sha512 kann durchaus mal eine Kollision vorkommen. Also auch da kurz prüfen, ob die Session-ID nicht schon in Benutzung ist - dauert ja nicht lange.
 
Zurück
Oben