# Methoden um Sessions zu missbrauchen



## GiFt-ZwErG (25. Februar 2007)

> Hallo,
> 
> ich arbeite gerade an meinem CMS und bin nun am überlegen wie ich bestimmte Daten des Users global verfügbar machen ohne jedes mal die MySQL DB zu quälen.
> Möchte nun gern die Daten in die Session speichern und habe dazu noch ein paar Fragen.
> ...



EDIT:
Habe mich nun etwas mehr eingelesen in die Sessions von PHP und frage mich nun ob es sinnvoll ist, diese zu nutzen.
Wenn der User Cookies deaktiviert hat, sind alle Daten aus der Session weg da der User eine neue Session zu gewiesen bekommt.
Und die übergabe der SessionID über die URL kommt definitiv nicht in Frage.
Gibt es eine Möglichkeit Daten ( Einstellungen des Users usw ) für alle Scripts verfügbar zu machen ohne diese jedes mal neu aus der Datenbank auslesen zu müssen?
Wobei dass ja die Session von PHP genauso macht oder? Bei jeder Session die gestartet wird, wird eine Datei erstellt wo die vars drin gespeichert werden.
Liest PHP diese Datei JEDESMAL neu aus? Könnte ja sein dass sich vars ändern usw.
Hat jemand eine ausführliche Seite über Sessions? Ich möchte alles darüber wissen wenn es geht.. habe schon die Seite http://www.php.net/manual/de/ref.session.php komplett durch... gibt es noch mehr was man über Sessions wissen muss?
Evtl auch Alternativen ( Klassen, Funktionen etc ) oder Hinweise auf andere Möglichkeiten etc.

MFG
Sandro


----------



## Radhad (26. Februar 2007)

Wenn Cookies deaktiviert sind wird die SessionID an die URL angehangen. Basiert dein Login-System mittels Auto-Login auf einer SessionID, kann mit Diebstahl des Cookies evtl. jemand an den Account des ursprünglichen Nutzers rankommen. Man hat nie eine 100%-ige Sicherheit, aber ich denke man sollte den User immer Aufmerksam vor möglichen Missbrauch machen.


----------



## Gumbo (26. Februar 2007)

Das HTTP, also das Transferprotokoll des WWWs, hat einen großen Nachteil: es ist zustandslos. Das heißt der User Agent muss sich auch nicht jedes Mal identifizieren und die Verbindung zwischen Client und Server wird nach jeder Anfrage getrennt. Das bedeutet wiederum, dass ein Benutzer auf seinem Weg durch eine Webanwendung nicht eindeutig identifiziert werden kann. Denn auch die IP-Adresse ist in Zeiten von gemeinsam genutzten Internetzugängen kein eindeutiges Merkmal.

Also hat man sich einen Trick ausgedacht, um eine eindeutige Identifizierung möglich zu machen. Nämlich eine Sitzungs-ID, die bei jeder Anfrage des Clients an den Server mitgeschickt wird – egal ob nun als Cookie, als GET- oder POST-Argument.

Doch dieser Trick stellt auch gleichzeitig die Schwachstelle des Systems dar. Denn PHP nimmt von Haus aus keinerlei besondere Validierung der Sitzungs-ID vor. Überhaupt ist die von PHP gebotene Sitzungsverwaltung wirklich nur sehr grundlegend. PHP bietet also quasi nur die Werkzeuge, mit denen der Entwickler seine Maschine bauen kann.

Daher ist es wichtig zu wissen, was eine Sitzung überhaupt ist und was sie nicht ist, was mit ihr möglich ist und was nicht, wo die Nachteile und Schwachstellen liegen und wie diese umgangen oder gestärkt werden können um einem Missbrauch vorzubeugen. Denn das Prinzip der Sitzung allgemein ist eigentlich sehr nützlich und oft auch notwendig. Nur die Implementierung ist oft sehr brüchig und unsicher gestaltet.

Lesenswerte Lektüre zum Thema sind die Artikel „The Truth about Sessions“ von Chris Shiflett sowie „Web Based Session Management“ von Gunter Ollmann. Auch die Websites beider Autoren sind sehr interessant und einen Blick wert.


----------



## GiFt-ZwErG (26. Februar 2007)

Ich danke dir Gumbo.
Ich werde mich noch ein bisschen informieren und dann entscheiden ob ich mir meine eigene "Session-Klasse" schreibe.
Das Problem ist leider, dass man den User schlecht identifizieren kann wenn er Cookies deaktiviert und dann evtl noch einen Proxy ( Anonymisierungsservice wie TOR und Co ) benutzt..
Wenn ich eine Klasse schreiben möchte die genauso arbeitet wie die Sessions von PHP, allerdings die Daten in der MySQL DB ablegt ( hab gelesen es soll 3 mal schneller sein diese auszulesen bzw 10 mal schneller wenn die DB schon geöffnet ist, was ja in fast jedem Script der Fall ist ) und die User anhand anderer Methoden bzw Merkmalen wieder erkennt als das Cookie oder die SessionID in der URL, welche Erkennungsmerkmal des User kann ich da noch nutzen? Wenn ich die IP nutzen würde, muss ich ja sicher gehen dass alle Daten der Sitzung dieser IP gelöscht werden wenn der User SEINE IP nicht mehr hat. Kann man da mit einem Timeout oder etwas ähnlichem arbeiten? Mir schwirren viele Ideen im Kopf aber mir fehlen noch ein paar Denkanstöße dazu 


Danke für die Hilfe
MFG
Sandro


----------



## Gumbo (26. Februar 2007)

Chris Shiftlett schlägt die User-Agent-Kennung vor, die – anders als die IP-Adresse – besser geeignet ist, um eine Anfrage auch über einen größeren Zeitraum zu validieren. Er setzt sie aber nur innerhalb der Sitzung selbst ein, um eine Sitzungs-ID eines User Agent zu validieren. Ich würde sie jedoch sogar als Teil des Sitzungs-ID-Bezeichners (Standardwert „PHPSESSID“) einsetzen und alle nicht passenden zurückweisen.


----------



## GiFt-ZwErG (26. Februar 2007)

Habe mir das Buch Sicherheitsrisiko Web-Anwendung von Sverre H. Huseby
( http://www.dpunkt.de/buecher/3-89864-259-3.html ) bestellt. Er behandelt dort unter anderem Crosssitescripting und SQL-Injections. 
Das mit der User-Agent-Kennung ist sehr unsicher da ich in meinem Firefox zb. das Plugin User-Agent-Switcher nutze um mein Statistikmodul zu testen.
Mit diesem kann ich mir jede erdenkliche User-Agent-Kennung geben und könnte mit der Session-ID in die Session einsteigen.

Sessions und Sicherheitsmechanismen bei Webanwendungen ist eine sehr interessante Angelegenheit 

Ich habe von einem User aus diesem Forum eine PM bekommen indem er sein System beschreibt.



> Ich hab da so n PHP Security-Buch gelesen (findeste auf amazon.de, "PHP-Sicherheit" heissts). Dadurch bin ich überhaupt so "gut" informiert, bzw. mein Sicherheitsdenken ist dadurch geweckt  empfiehlt sich das mal anzuschaffen, auch wenns nicht unbedingt billig ist.
> 
> Okay, jedenfalls bin ich da stark ins grübeln gekommen. Man sagt, man solle auf die PHPSession-Funktion zurückgreifen und KEINE Userdaten im Cookie speichern. im selben buch steht aber auch, dass man per XSS-Angriffe (im hauptsächlichen durch einbringen von HTML-Code in die Datenbank) Cookies auslesen kann - und die SessionID von PHP wird als Cookie gespeichert. Du wirst nun wohl sehen worauf ich hinaus will: Kann man XSS durchführen, kann man sich die SessionIDs erschleichen und sich selbst ein Cookie setzen - und zack, hat man womöglich sogar zugriff auf einen Adminaccount. Fatal.
> 
> ...



Das ist die PM mit der Beschreibung seines Systems.
Ich habe es mit angeschaut aber leider nutzt mir die Methode mit den Cookies nix.
Aber die Idee mit dem 128bit Schlüssel ( ID ) die alle 60 sek neu generiert wird ist sehr interessant.
Leider basiert das alles auf Cookies ( die deaktiviert werden können ) oder URL-Parameter ( die mir zu unsicher sind )

MFG
Sandro


----------



## Gumbo (26. Februar 2007)

GiFt-ZwErG hat gesagt.:


> Das mit der User-Agent-Kennung ist sehr unsicher da ich in meinem Firefox zb. das Plugin User-Agent-Switcher nutze um mein Statistikmodul zu testen.
> Mit diesem kann ich mir jede erdenkliche User-Agent-Kennung geben und könnte mit der Session-ID in die Session einsteigen.


Die Berücksichtigung der User-Agent-Kennung würde selbstverständlich mehr Sicherheit bieten, da nur ein aus der User-Agent-Kennung generierter Sitzungs-ID-Bezeichner akzeptiert würde. Und selbst wenn die User-Agent-Kennung fehlt oder leer ist, wäre der generierte Sitzungs-ID-Bezeichner ein anderer als das allzu offensichtliche „PHPSESSID“.
Die Frage ist dann allerdings, was passieren soll, wenn die User-Agent-Kennung sich ändert, da beispielsweise der Webbrowser aktualisiert wurde. Dort wäre dann – falls es Teil eines Authentifizierungssystems ist – eine Authentifizierung des Benutzers nötig.


----------



## versuch13 (9. März 2007)

Ok, ich habe keine großen PHP Kenntnisse, daher wenn ich einen Login realisieren würde, würde ich per Formular Username und Passwort übergeben, die Post Daten mit Daten in der Datenbank vergleichen, wenn die Daten übereinstimmen eine Session starten, z.B. $_SESSION['loggedin']. Es würde nichts per URL übergeben werden. Bedeutet also Cookies müssen aktiviert sein, was mich aber nicht stört. Ist die Session gesetzt, bekommt der User  Zugang zu den "geheimen" Daten, andernfalls eben nicht.
Für einen dauerhaften Login würde ich einen Cookie setzen, auch einfach nur $_COOKIE['loggedin']. Ist dieser gesetzt wird ebenfalls zutritt gewährt. Zum ausloggen wird die Session und der Cookie gelöscht. Ich speichere also keine Userdaten, wie Name oder Passwort in der Session oder dem Cookie. Ist das jetzt irgendwie super Risiko behaftet?

Und danke für die Links, Gumbo, sieht interessant aus, werde ich mir wenn Zeit ist alles mal genauer ansehen.


----------



## Gumbo (9. März 2007)

Eigene Cookies anzulegen ist mit vielen Browsern ein Kinderspiel. Denn entweder besitzt der Webbrowser selbst schon eine solche Funktion oder sie lässt sich durch Erweiterungen bequem nachrüsten. Notfalls kann der Cookie auch direkt am Speicherort der Cookies hinzugefügt werden, kennt man sich mit dem Webbrowser etwas aus. So wäre es also eine Leichtigkeit sich als jemand anderes beim System anzumelden, hat man erst mal die Sitzungs-ID eines Benutzers.
Wird die Sitzungs-ID regelmäßig gewechselt, kann der Schutz vor einer solchen Entführung der Sitzung erhöht werden. Zusätzlich kann auch eine weitere Validierung der Anfrage (beispielsweise der Vergleich der User-Agent-Kennung) die Sicherheit erhöhen. Das System sollte dann aber natürlich auf ungültige Anfragen entsprechend reagieren, um einen Missbrauchsversuch zu verhindern.


----------



## versuch13 (9. März 2007)

Ja ok, aber wenn ich die Sitzungs ID nicht über die URL übergebe, wo wird sie noch für einen möglichen Angreifer sichtbar? Wird sie das überhaupt? Also in meinem Beispiel, wäre es also für einen Angreifer möglich, die $_SESSION['loggedin'] ganz einfach zu fälschen?


----------



## Gumbo (9. März 2007)

Die Sitzungsdaten selbst können nicht verändert werden, da dies nur über das Skript geht. Es reicht aber eine gültige Sitzungs-ID zu haben, die beispielsweise durch Cross-Site Scripting besorgt werden kann.


----------



## versuch13 (9. März 2007)

Aha, also wenn eine Seite vollkommen gegen XXS gesichert wäre, wäre eine User Authentifizierung anhand einer Session Variable oder eines Cookies also sicher?

Hier gibt es eine Tutorial zu einer Userverwaltung + Login usw.



			
				Aus dem Tutorial hat gesagt.:
			
		

> Ein Hacker könnte ja auf die Idee kommen, 1000 Anfragen pro Sekunde zu senden. Das würde durch sleep(2); abgehalten werden, da er immer 2 Sekunden auf die Antwort warten müsste. Nun könnte er seine Programm aber sagen, breche nach 2 Sekunden ab! Deswegen wird hier bei einem korrekten Login ein variables Timeout des Server simuliert. Bei fehlgeschlagenem Login auch, welches jedoch etwas größer ist!



--> 14ter Code Block..  

Wäre das noch eine weiter Möglichkeit sich vor Angriffen zu schützen? Nach der DB Abfrage und  Vergleich des Namens und Passwortes, bevor man Session oder Cookie setzt, sleep anwenden?


Sorry wenn ich das Niveau des Threads wohl etwas runterziehe, aber irgendwie muss man ja in das Thema reinkommen.


Danke


----------



## Gumbo (9. März 2007)

versuch13 hat gesagt.:


> Aha, also wenn eine Seite vollkommen gegen XXS gesichert wäre, wäre eine User Authentifizierung anhand einer Session Variable oder eines Cookies also sicher?


Nein, das heißt es leider nicht. Denn Cross-Site Scripting ist nur eine Möglichkeit an Cookie-Daten zu kommen. Es gibt aber noch andere, die jedoch wohl seltener ausgenutzt werden, da sie komplizierter oder ineffizienter sind. Ein Schutz gegen Cross-Site Scripting ist aber ein guter Anfang.



versuch13 hat gesagt.:


> Wäre das noch eine weiter Möglichkeit sich vor Angriffen zu schützen? Nach der DB Abfrage und Vergleich des Namens und Passwortes, bevor man Session oder Cookie setzt, sleep anwenden?


Wenn 1000 Anfragen von einem einzigen Client innerhalb einer Sekunde eingehen, sollte spätestens nach der dritten, fünften oder zehnten der Server alle weiteren automatisch abweisen.


----------



## versuch13 (9. März 2007)

Ok, besten Dank!


----------

