Angst vor Lücken

Zitat von Lasagne

Das klingt super. Aber was hat es mit den Sessions auf sich? Wie kann es zum Beispiel passieren, dass selbst in großen Hotels
Mitarbeiter gehackt wurden/werden? Hat das beispielsweise mit Vergesslichkeit des Programmierers zu tun, oder
gibt es da Dinge, die man nochmal absichern muss?

Session Hijacking.
Müsstest einfach nur beim Login den Nutzername UND das Passwort speichern.
In der If Abfrage wo geprüft wird, ob der User eingeloggt ist - müsste geprüft werden, ob die beiden Sessions gesetzt sind und
es in der Datenbank dazu auch ein passendes Feld existiert.

Zitat von Lasagne

Das klingt super. Aber was hat es mit den Sessions auf sich? Wie kann es zum Beispiel passieren, dass selbst in großen Hotels
Mitarbeiter gehackt wurden/werden? Hat das beispielsweise mit Vergesslichkeit des Programmierers zu tun, oder
gibt es da Dinge, die man nochmal absichern muss?

Retro Hotels werden oft durch SQL Injection gehackt. Der Hacker veschafft sich durch eine SQLi Lücke Zugriff auf die Datenbank und liest die Usernamen und Passwörter der User ab. Doch wie kommt er jetzt in die Accounts? Die Passwörter werden in den meisten CMSen der deutschen Retro Hotels doch in MD5 verschlüsselt, sodass ein Hacker selbst durch Wissen über den MD5-Hash nur extrem schwer in die Accounts kommen kann? Durch "Cookies", die beim User beim Einloggen gesetzt werden, kann der Hacker trotzdem in die Accounts. Er tauscht einfach seinen Benutzernamen und sein Passwort, die Werte solcher Cookies sind, durch die des Opfers aus. Nun muss er lediglich noch die Seite reloaden und ist im Account des Opfers.

Um Session Hijacking zu verhindern, gibt es viele Lösungen. Eine Überprüfung, ob die IP-Adresse des Benutzers noch die selbe ist, wie die beim Einloggen, ist wohl eine der einfachsten.

Ist beides möglich. Session Einträge werden jedoch nach einem Browser Neustart gelöscht. Wenn du also nicht willst, dass der IP-Adressen-Eintrag in der Session gelöscht wird, dann lasse die IP-Adresse des Users beim Einloggen in die Datenbank speichern. Jetzt kannst du bei jedem Seitenaufruf des Users mittels dem Datenbankeintrages überprüfen lassen, ob der Wert in der Datenbank sich der aktuellen IP-Adresse gleicht. Wenn nicht, dann kannst du den User ausloggen lassen.

An der Session kann ein User von außen nichts ändern, denn PHP ist serverseitig.
MFG

B2T:
PHP & MySQL lernen und fertig.

Zitat von Lasagne

Hab mich fast kaputt gelacht
Hatte auf konstruktive Antworten gesetzt, war aber klar dass jemand
aus der Reihe tanzen muss.

Ist doch Konstruktiv?
Und thx, wollte das schon lange mal machen

Zitat von Azcaq

Müsstest einfach nur beim Login den Nutzername UND das Passwort speichern.
In der If Abfrage wo geprüft wird, ob der User eingeloggt ist - müsste geprüft werden, ob die beiden Sessions gesetzt sind und
es in der Datenbank dazu auch ein passendes Feld existiert.

Welchen Sinn hätte das?
Ich denke du prüfst doch schon beim Login ob die Benutzerdaten überein stimmen. So erzeugst du nur unnötig SQL Querys und beeinträchtigst die Leistung deiner Seite. Da die Sessions sowieso auf dem Server gespeichert werden, kann man die so leicht auch nicht manipulieren.

Überleg mal wie Session Hijacking funktioniert. Da bringt dir das Speichern des Benutzernamens und Kennwortes garnichts.

Die einzige Sicherheitsvorkehrung bezüglich der Cookies wäre z.B. überprüfen ob sich clientspezifische Variablen wie z.B. die IP Adresse verändert haben. Also zum Beginn der Session die IP speichern und sobald die IP, mit der in der Session Variable nicht mehr überein stimmt, die Session entwerten.

----

Zur Frage des Theadstellers:
OOP ist einfach ein cooler Begriff den alle coolen in der Szene verwenden müssen. OOP macht bei großen Projekten natürlich Sinn. Von Qualität des Codes oder besonders großer Sicherheit zeugt OOP alleine aber nicht. Für eine einfache, kennwortgeschützte Seite eine ganze Klasse zu definieren ist purze Zeitverschwendung.

Die Verwendung des mysql-Moduls ist soweit auch komplett bedenkenlos möglich. Die einzige Gefahr die besteht, ist dass dieses Modul als veraltet markiert wurde und in späteren PHP Versionen entfernt werden könnte. Sicherheitstechnisch kannst du bzw dein Freund aber weiterhin "mysql_real_escape_string" verwenden.