Ist mein Login-Script sicher?

[Weede]

Zitat von Driver

Gibt es denn eine Möglichkeit mit PHP den Anbieter eines Users rauszubekommen? Wahrscheinlich nicht

eigentlich schon, aber dazu müßte man wissen welche ip-bereiche AOL für sich reserviert hat... eher fragwürdig, als sinnvoll das zu versuchen

[seb]

Ich hab jetzt einige Artikel zum Thema Sicherheit von PHP-Sessions durchgelesen, zuletzt diesen hier, welchen ich besonders gut finde.

Für diejenigen, die zum Lesen zu faul und/oder in Englisch nicht so fit sind, hier das Fazit in Stichpunkten:

1. Hundertprozentige Sicherheit ist unerreichbar.

2. Sicherheitschecks, die auf TCP/IP-Daten beruhen, sind unbrauchbar, da für den Webserver sowohl viele User wie einer (gleiche IP-Adresse für alle Computer, die über einen Gateway/Proxy auf den Webserver zugreifen) als auch einer wie viele (ständig wechselnde IP-Adresse z.B. bei AOL) erscheinen können.

3. Daraus folgt, dass zur sicheren Authentifizierung eines Users bzw. einer einzelnen Browser-Instanz nur die gesendeten HTTP-Header zur Verfügung stehen.
Eine relativ unproblematische Möglichkeit zur Erhöhung der Session-Sicherheit ist es also, zusätzlich zur Session-ID die vom Browser gesendeten Header-Daten (z.B. HTTP_USER_AGENT, am besten mehrere kombiniert) für die Laufzeit der Session zu speichern und bei jeder Anfrage zu vergleichen.

[Driver]

Hmm, also ich hab mir grad das hier angeschaut und es sieht ja nicht so kompliziert aus. Aber was genau sollte man dann wie abgleichen?

[seb]

Ich hab in mein Script jetzt folgende Zeilen eingebaut:

PHP-Code:


session_start(); // sowieso, war auch vorher schon da

/*
Generiere den MD5-Schlüssel von Browser-Kennung ($_SERVER['HTTP_USER_AGENT']) + definiertem Pfad-Raum des Client-Betriebssystems ($_SERVER['PATH']):
*/

$user_agent_auth_key = md5($_SERVER['HTTP_USER_AGENT'] . $_SERVER['PATH']);

/*
Falls $_SESSION['USER_AGENT_AUTH_KEY'] leer ist (d.h. immer zu Beginn einer neuen Session), fülle die Variable mit dem oben generierten Schlüssel:
*/


if (!$_SESSION['USER_AGENT_AUTH_KEY']) $_SESSION['USER_AGENT_AUTH_KEY'] = $user_agent_auth_key);


/*
Überprüfe bei jeder folgenden Anfrage, ob der (bei jeder Anfrage neu generierte) Schlüssel mit dem in der Session gespeicherten übereinstimmt. Wenn nicht, beende das Script:
*/

if ($_SESSION['USER_AGENT_AUTH_KEY'] != $user_agent_auth_key) die('Fehler bei der Authentifizierung Ihres Browsers. Beenden Sie Ihren Browser komplett (alle Browserfenster schließen) und beginnen Sie Ihre Sitzung neu.'); 


Dieser Check ist sehr simpel, aber effektiv - die Wahrscheinlichkeit des erfolgreichen "Stehlens" einer Session wird damit erheblich reduziert, da ein erfolgreicher Session-Dieb sowohl exakt die selbe Kombination von Browser und Betriebssystem als auch exakt die selben Path-Einstellungen im Betriebssystem haben muss wie der rechtmäßige Besitzer der Session.

Insbesondere die Überprüfung von $_SERVER['PATH'] erscheint mir sehr zuverlässig. In dieser Variable stehen bei mir Einstellungen verschiedenster Programme, u.a. dem ATI Control Panel und dem GIMP Toolkit (GTK+). Dass diesen String jemand errät, ist doch sehr unwahrscheinlich.

Einziger Nachteil:

Browser-Kennung und Path-Definitionen des Betriebssystems dürfen sich während der Laufzeit der Session nicht ändern, sonst wird auch der rechtmäßige Session-Besitzer abgewiesen. Da das aber unwahrscheinlich ist, kann man es ignorieren.

Und:

Ein 100%iger Schutz ist das natürlich trotzdem nicht, da ein Einbrecher theoretisch auch diese Daten abfangen und seine "böse" HTTP-Anfrage entsprechend angleichen kann. Davor schützt letztlich nur eine verschlüsselte Verbindung per SSL.

[Driver]

OK, danke, hab das jetzt verwendet.
Hätte jetzt aber noch eine kleine Frage. Mein Login unterscheidet zwischen Groß- und Kleinschreibung. Wie kann ich das berhindern, dass es also egal ist, ob ich als Nick Test oder test eingebe. Ich meine, da mal einen Befehl gelesen zu haben, aber den finde ich grad nicht.

[seb]

Speichern + Vergleich mit

PHP-Code:

strtolower($login) 


?

[Boris]

Also ich finde es nicht so sehr unwarscheinlich, dass mehrere User das gleiche OS (WinXP) und den gleichen Browser (IE6) benutzen ...

Das mit dem "Fingerprint" ist aber eine recht gute Idee, finde ich ... das mit dem PATH überzeugt mich noch nicht so ganz - was genau wird darin gespeichert? Bei mir wäre es (lokal): C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem

[seb]

Also ich finde es nicht so sehr unwascheinlich, dass mehrere User das gleiche OS (WinXP) und den gleichen Browser (IE6) benutzen

Viel mehr geht halt nicht, wenn man niemanden wegen wechselnder IP-Adresse aussperren will. Dabei wäre ein IP-Adressen-Check natürlich weitaus sicherer als so was. Man könnte ihn noch optional dazubauen, so dass ihn User mit beständiger IP-Adresse (dürften ja zum Glück die meisten sein) für zusätzliche Sicherheit aktivieren können.

[Boris]

Ich finde dieses Beitrag recht interessant. Wir könnten hier das "bestmögliche" Loginsystem erstellen

Was die Sicherheit z.B. auch erhöhen kann (aber die Usuability für den User einschränkt), ist es zu deaktivieren, dass PHP automatisch die Sessions an die URL hängt, falls kein Cookie angelegt werden kann.

In meinen Loginsystemem habe ich zwar nicht die IP gespeichert und verglichen (wär bei Proxies fatal), aber etwas anderes - den "echten" Host, mit Hilfe von gethostbyaddr ... ob da AOL User auch ausgesperrt werden?

[seb]

Was die Sicherheit z.B. auch erhöhen kann (aber die Usuability für den User einschränkt), ist es zu deaktivieren, dass PHP automatisch die Sessions an die URL hängt, falls kein Cookie angelegt werden kann.

Jo. Das stell ich bei meinen Sites grundsätzlich ab. Als Usability-Einschränkung würd ich's nicht bezeichnen...die Leute müssen bloß kapieren, dass Cookies nichts böses sind.

In meinen Loginsystemem habe ich zwar nicht die IP gespeichert und verglichen (wär bei Proxies fatal),

Naja...es ist kein Problem, wenn der Proxy bzw. seine IP-Adresse während der Session gleich bleibt. Die Sicherheitsüberprüfung wäre dann zwar wirkungslos, wenn die Anfragen eines Einbrechers über den gleichen Proxy laufen, aber zumindest gegen den Rest der Welt wäre man abgesichert. Man erreicht also schon ein Stück mehr Sicherheit, und das sollte man nutzen (wenn Sachen wie AOL nicht wären).

aber etwas anderes - den "echten" Host, mit Hilfe von gethostbyaddr ... ob da AOL User auch ausgesperrt werden?

Offenbar ja. Wie gesagt, das AOL-Problem wird in praktisch jedem Artikel, den ich gestern gelesen habe, angesprochen. Wenn es eine Lösung gäbe, müsste die auch irgendwo beschrieben sein, aber ich hab nichts gefunden.

[|23|]

Da ich Boris Worten nur zustimmen kann: “Ich finde dieses Beitrag recht interessant“ und selber an einer Ausarbeitung eines „Loginsystemem“ für eine Internen Bereich bin. Habe ich eine Anregung. Die Login Namen, Passwörter etc. werden doch sicher in einer Datenbanken gespeichert. z.b MySQL, ich sehe hier aber ein Risiko.

Da ihr derzeit nur diskutiert hab wie ihr es verhindern könnt, dass ein fremder User in dem Internen Bereich kommt. Sprich durch Session fake etc. Würde es mich mal interesiern wie es mit der Datenbank Sicherheit ausschaut.

Und ein andere Punkt wer es nicht sinnvoll die ganze Kommunikation mit SSL abzusichern!? und wenn ja wo sind die Vorteile und die Nachteil. Wie sehr leidet die Geschwindigkeit/Aufbau der Seite?


mfg

|23|

[steffenk]

Und ein andere Punkt wer es nicht sinnvoll die ganze Kommunikation mit SSL abzusichern!? und wenn ja wo sind die Vorteile und die Nachteil. Wie sehr leidet die Geschwindigkeit/Aufbau der Seite?

Sehr.
SSL setzt ausserdem vorraus, das die Server richtig konfiguriert sind und ein gültiges Zertifikat existiert. Meine Erfahrungen haben gezeigt, das viele Systeme nicht vollständig mit SSL konfiguriert sind, Zertifikate meist Pseudo-Zertifikate sind.
Nicht umsonst gibt es Services, die Zertifikate für gutes Geld verkaufen.

Die Datenbank ist so sicher wie man sich um die Sicherheit bemüht.
Wenn man Injecting verhindert, die Zugangsdaten nicht zugänglich macht, keinen Fernzugriff zulässt etc., ist das schon eine sichere Sache.
Aber ob die Daten nun in einer DB oder in einem nicht zugänglichem File liegen, ist eigentlich egal.
Ich bevorzuge sensible Files in den Bereich zu legen, der ausserhalb des Webspaces liegt.

[DSB]

Ich schmeiße einfach mal eine Idee in den Raum.
Bisher basiert ja das Sessionsystem darauf, dass eine eindeutige Sessionnummer generiert wird, die dann beibehalten wird.
Gelangt jemand anders an die Session kann er sich darüber einloggen und Inhalte sehen, die nicht für ihn bestimmt sind.

Wie wäre es denn, wenn die Session nur für einen einzigen Seitenaufruf gültig wäre, sofort verfällt und jedes Mal eine neue Nummer generiert und wieder mitgeschickt wird?
So ist die Session nur für einen Aufruf gültig und kann auch nur einmal benutzt werden.
Gut, refreshen darf man eine Seite dann zwar nicht, aber es wäre doch sicher oder? Es wären natürlich noch weitere technische Finessen zu umschiffen aber die Grundidee kann man ja mal durchspielen...

[skipperjan]

Ein sehr interessanter thread muss ich sagen da hätte ich dann auch nohc eine kleine Frage.

Da man den IP Check ja leider nicht wirklich verwenden kann und somit die Session gestohlen werden könnte, habe ich der session des Users noch einen Zufalls Schlüssel zugeordnet der in der Session gespeichert wird, nur wenn beide Werte existieren ist die session gültig, die Session-Id wird in einer DB gespeichert, dort werden jeweils max. 100 Sessions gespeichert, dann werden die 50 ältesten gelöscht.

Die Idee war, wenn jemand mit einer geklauten Session um die Ecke kommt und diese noch in der DB steht, also doppelt verwendet werden soll, dann fliegt er raus. Besser gesagt beide. Da beide die identische Fehlerseite präsentiert bekommen, dann kann sich der gültige User ja wieder einloggen. Eine einmal verwendete Session-id ist also verbrannt. An allen stellen mit schützenswerten Inhalten wird ein kurzer Abgleich mit der DB vorgenommen, das geht aber ratzfatz, da dort nur eine Session, eine Zufallszahl und ein Primärschlüssel drinstehen.

Zu aufwendig? Oder vielleicht doch zu knacken?

So long,

skip

[Stuck Mojo]

@skipperjan: Das macht keinen Unterschied! Da der Zufallswert nunmal der Session zugeordnet ist... und wer die session klaut, hat natürlich auch die Inhalte, wie z.B. den Zufallswert.

Gruss
Jan