Eigene Mitgliederverwaltung und Sicherheit

[Bademeister]

Hi Headdy,

Beim Registrieren werden die Daten (erstmal Nickname und PW) mit md5 verschlüsselt und in einer MySQL-Tabelle gesichert.

Es gibt keinen Grund, den Nicknamen zu verschlüsseln. Der Zweck des Verschlüsselns in der Datenbank ist, dass ein Blick in die Datenbank nicht die "Login-Informationen" freigibt. Dafür reicht es, das Passwort zu verschlüsseln. Den Nicknamen eines Benutzers wirst Du aber eventuell brauchen können, um Ihn anzureden. Nicknamen ist keine geheimen Daten (Nach dem Login hättest Du ihn ggf. auch so zur Verfügung, aber für eventuelle automatische Emails o.ä. bräuchtest Du ihn aus der Datenbank).

Ich möchte das ganze ohne Sessions machen (da ich davon nicht viel Ahnung habe und in anderen Foren auf Beiträge mit Problemen bei Sessions gestoßen bin).

Wenn Du Sicherheitsprobleme meinst - die wirst Du alle auch mindestens gleichermaßen mit Deiner Konstruktion haben. Ich sehe nicht den geringsten Vorteil Deines Planes, eine Sassion "von Hand zu bauen", gegenüber einer PHP-Session. Im Gegenteil, wenn Du da nicht genau weißt, was Du tust, kannst Du Dir damit große Probleme schaffen. Und weniger komfortabel ist es so oder so. Zwei Apskte, die mir spontan einfallen:

• Du würdest, wenn ich Dich richtig verstehe, alle sessionbezogenen Daten in der Datenbank speichern. Da brauchst Du ein gutes Datenbankdesign oder Du wirst sehr unflexibel, was eventuelle Weiterentwicklungen der Website angeht.

• Du musst gut aufpassen, dass Deine generierten Session-IDs eindeutig sind. Mit Deinen md5-Ansätzen zur Erzeugung verlässt Du Dich dabei auf die Stochastik (oder willst Du bei jedem Erzeugen alle existierenden IDs vergleichen?). Das wird wahrscheinlich gutgehen in der Praxis, aber sauber ist es nicht.

Die Pseudo-Session-ID müsste zum übertragen per POST dann jedoch auf jeder Seite in einem versteckten Formular schlummern. Da liegt mein Bedenken zur Sicherheit.

Ein grundsätzliches potentielles Sicherheitsproblem jeder Session (ob PHP- oder "von Hand gebaut" oder was auch immer) ist: Der Benutzer muss sich bei seinem HTTP-Request identifizieren, d.h. eine Information (die Session-ID) schicken, die (im besten Fall) nur er kennt. D.h. man kommt nicht drumrum, dass die ID, während ein Benutzer eingeloggt ist, irgendwo im Client-Rechner zu finden ist - sei es in einem Cookie oder im beim letzten Request gesendeten Quellcode. Wenn nun andere Leute Zugang zu dem Rechner haben, dann können sie gegebenenfalls die ID herausfinden. Das ist nicht schön, aber nicht zu vermeiden.

Damit es für den Benutzer möglich ist zu jeder beliebeigen Seite zu wechseln, müsste folgendes gegeben sein: Der Seitenlink auf den der Benutzer klickt, müsste eine Javascript-Fkt aufrufen, die im Pseudo-Session-ID-Formular, den action-Attribut ändert (auf die gewünschte Seite).

Ist dieses Script dann eine zusätzliche Sicherheitslücke?

Nicht wirklich. User könnten das Skript zwar manipulieren, aber da hätten sie nicht viel von. Wenn sie das Ziel eines "Links" oder die Session-ID für den nächsten Request manipulieren wollten, können sie gleich das Formular direkt manipulieren und abschicken. Aber es ist extrem umständlich (denke z.B. daran, dass auch alle eventuellen echten Formulare, die Du irgendwo verwendest, mit der Session-ID gefüttert werden müssten), und bringt den generellen Der-User-braucht-JavaScipt-Nachteil mit sich.

Ich rate Dir also energisch von diesem Eigenbau der Sessions ab.

viele Grüße
der Bademeister