ich bin grad dabei für ne Seite nen Loginbereich zu erstellen, jetzt dachte ich mir, ich frag mal so in die Runde wie ihr das ganze so absichert. Damit die eingaben geprüft werden sollen, und Passwort verschlüsselt abgespeichert werden soll ist klar.
Am sichersten wäre ja denke ich Session + IP vergleich(mysql-db),
folgende Probleme stellen sich mir jetzt erstmal gedanklich:
IP wechselt alle 24 (alternativ - nur die ersten 6 Zahlen vergleichen)
Dauerlogin sollte möglich sein, und dennoch sicher
ich schätze den Dauerlogin realisiert man am besten über cookies oder?
Die IP kann sich auch von einem Request zum nächsten schon geändert haben, wenn der Nutzer über verschiedene Proxies zugreift. (Muss er nicht freiwillig machen, teilweise sorgen auch die Zugangsprovider dafür.)
Ja, wobei sich dann erst die eigentlich interessante Frage stellt, was man in diesen Cookie reinschreibt. Sollte auf jeden Fall auch irgendein Hash sein, keinesfalls nachvollziehbare Daten wie Username und/oder Passwort.
Und „ewig“ sollte der Cookie auch nicht leben, maximal ein paar Tage.
Die fehlende Absicherung gegen SQL Injection ist das größte Manko, das sofort ins Auge fällt.
Und damit kann man dieses Tutorial gleich in die Kategorie „Finger von lassen“ einordnen; ganz abgesehen von weiteren Mängeln wie fehlender Fehlerbehandlung etc.
zu IP: wollte eigenlich schreiben normalerweise spätestens alle 24 Std(Zwangstrennung Provider) aber war mir dann doch zu ausführlich.
zum Cookie:
genau jetzt sind wir an dem Punkt den auch ich meine:
Ich am besten wäre ja irgendein einzigartiger “Stempel”. Da ich die Logins eh loggen will, könnte man ja da ja vielleicht aus ner log id und nem weiteren wert was zusammenschustern.
und die abfrage in etwa so oder?
if(Session & IP korrekt vollständig)
{
eingeloggt
} elseif(cookie gesetzt und wert korrekt) {
eingeloggt -IP aktualiersieren}
else {
falsch - cookie und session zerstören
}
ich nutz sowas ähnliches bei nem neuen sich noch in der entwicklung befindlichen projekt:
[code] $session_ok = $row3->Session;
}
if($session_ok == $session_id)
{
$change = "UPDATE login Set
Datum = '$datum'
WHERE Session = '$session_id'";
$update = mysql_query($change);
}else{[/code]
Das script speichert beim login datum, zeit, ip, sowie die derzeitig session_id
der teil fragt es ab und wenn die abfrage erfolgreich war, gibt das script den zugang frei
[quote=“Mr.Generation”]Das script speichert beim login datum, zeit, ip, sowie die derzeitig session_id
der teil fragt es ab und wenn die abfrage erfolgreich war, gibt das script den zugang frei[/quote]
Was fragt dein Script ab - das Datum?
Hoffentlich nicht wirklich (nur) das Datum.
Denn wenn ein Script meint, mich kurz nach Mitternacht als nicht eingeloggt betrachten zu dürfen, nur weil ich mich kurz vor eingeloggt habe, dann taugt es nichts.
Und was ihr immer alle mit der IP habt, verstehe ich wirklich nicht …
[quote=“Mr.Generation”]@kalkal: mein script list die session_id des browsers intern aus.
der link enthält keinerlei sessionIDs oder ähnliches ^^[/quote]
erklär das mal genauer wie du das anstellst
wenn php man cookies nicht zulässt hängt php automatisch die SID an meines Wissens
ich eröffne zuerst im header eine session und speichere die session_id in einer variable zwischen. die headerdatei wird dann von der entsprechenden unterseite includiert und eingelesen. die session_id des browsers ändert sich für den aufenthalt nicht (bei meinem firefox geht das wohl auch über mehrere tage) und bleibt somit gleich. die session_id wird bei jeder neuen unterseite neu eingelesen bzw ausgelesen und verwendet. das bedeutet das ich nicht darauf angewiesen bin, die session id von einer seite zur anderen zu senden oder mit “GET” zu holen
und der Browser speichert sie als Cookie sofern sie aktiv sind.
Geh jetzt einfach mal auf deine Seite und deaktivier die Cookies, und dann schnau mal was mit den Links gemacht wird. Und jetzt brauchste nichtmal nen DAU haben, sondern nur jemand der technisch nicht sonderlich genau auskennt, und der fragt z.B ob der Artikel eines onlineshops was taugt und postet dabei den Link…
Ja - weil sie in einem Cookie gespeichert ist, und der Browser dessen Inhalt bei jedem Request wieder mitschickt.
Ach, und woher wird die eingelesen?
Sessions basieren darauf, dass der Browser bei jedem Request die Session-ID erneut mitschickt - sonst wüsste dein Script nichts von ihr, könnte also den Client nicht identifizieren.
Und dieses Mitschicken funktioniert entweder per Cookie - oder, wenn das nicht geht, als Fallback per GET oder POST.
Dann wird die Session-ID also wohl per Cookie übermittelt - gut, dass ist der Normalfall.
Es wird selbstverständlich ein Request gesendet, wenn dein Browser eine neue Seite anfordert, oder ein Formular abschickt.
Ob dabei di Session-ID auf einem anderen Weg als per Cookie mitgesendet wird, hängt von den Umständen ab.
Dann „funktioniert“ aber auch deine Session nicht mehr - wenn die ID dann nicht auf anderem Wege übermittelt wird.
Das ist schön für das Script.
Aber wenn ein neuer Request reinkommt, bedeutet das auch eine neue Scriptinstanz. Und die muss die Session-ID übergeben bekommen - sonst wird eine neue Session erzeugt, und mit der bist du dann nicht mehr „eingeloggt“ oder wasauchimmer.
Das ist kein Zank - wir versuchen dir nur verständlich zu machen, dass du die Funktionweise von Sessions bisher ganz offensichtlich noch nicht vollständig verstanden hast.
Das ist möglich, nur wundert es mich das wenn ich im IE mit deaktivierten Cookies mich einloggen kann, auf die nächste Seite gehen kann, dort fleißig F5 Spam veranstalten kann und alle Funktionen nutzen kann, ohne das ich rausflieg.
D.h. irgendwas in meinem Script sorgt dafür, dass meine „Session“ (die scheinbar keine ist) aufrecht erhalten wird, selbst ohne Cookies. Wie auch immer das funktioniert ^^
Das ist absolut das Verhalten, was zu erwarten ist - PHP fügt die Session-ID automatisch an die Adresse an, weil es so konfiguriert ist.
Und auf jeder anderen Seite, die Sessions, so wie sie in PHP eingebaut sind, nutzt, ist das auch nicht anders. Es sei denn natürlich, es wäre entsprechend konfiguriert, dass dieser Fallback nicht genutzt werden soll - dann „funktionieren“ auf diesen Seiten aber auch keine Sessions.
