Hi Forum,

wie ihr vllt merkt befasse ich mich gerade mit dem Thema Sicherheit in Webanwendungen. (siehe anderer Fred)

Habe mir gedacht (oder gehofft), wir könnten hier ein paar themen durchkauen im Bezug auf die Sicherheit von Webanwendungen. Da hier ja auch studierte Fachleute aktiv sind, hab ich großes Vertrauen in dieses Forum (im gegensatz zu anderen, in denen lediglich Posts aus anderen Foren in abgeänderter Form wiedergegeben werden und keiner eigntl so recht weiß, was er eigentlich von sich gibt )

Vielleicht könnten wir mal mit den Sessions anfangen und uns danach weiterhangeln. Wär toll das mit euch durchzukauen und euere Meinungen zu hören.

Ich bringe mal ein paar Infos:

Session-Fixation
Wie Ihr sicher alle wisst, werden Sessionschlüssel (sog. Sesson-ID's) für die zur Identifizierung in Webanwendungen benutzt. Die Methode der Session-Fixation ist ein Angriff auf eben diese Schlüssel.
Php erzeugt so einen Schlüssel mit einer sehr hohen Zufallswahrscheinlichkeit und generiert so 32 Stellen für eine SessionID. Folglich ist dieser Schlüssel sehr schwer zu erraten.

Die einfachste Methode sich unberechtigt Zugang zu verschaffen ist also, den Schlüssel vorzugeben. Zusätzlich muss der Angreifer einen user dazu bewegen, seinen selbst generierten Schlüssel zu verwenden.

Erich Kachel hat hierzu eine Recht anschauliche Realsitation beschrieben:

In einem Bahnhofsgebäude befinden sich Schließfächer. Ein Angreifer verwendet ein Schließfach, entnimmt den Schlüssel und fertigt eine Kopie an. Anschließend gibt er das Schließfach wieder frei. Verwendet ein Opfer anschließend dasselbe Schließfach, so besitzt der Angreifer bereits einen passenden Schlüssel dazu. Da an solche Schließfächer keine weiteren Kontrollen (Identitätskontrolle, einmaliger Zugangscode) stattfinden, genügt der Besitz des Schlüssels um an fremde Inhalte zu kommen.

Es genügt also, dem Opfer lediglich ein Link oder ein Cookie unterzuschieben, das schon eine SessionID enthält. Surft nun das Opfer auf euere Seite und meldet sich an, (z.b mit user: Horst pw: Köhler) wir die Session (mit der vom Angreifer generierten ID) dem user Horst mit dem Passwort köhler zugewiesen.

Der Angreifer kann nun die Identität des Users annehmen, da er mit der selben SessionID die Seite besucht. Die Anwendung denk also, der Angreifer wäre Horst und gewährt im Zutritt.

Ich verlinke hierzu ein Bild, das die Sache etwas veranschaulicht:
[Blockierte Grafik: http://www.erich-kachel.de/wp-content/uploads/2008/09/screenshot31.png]
Quelle: erich-kachel.de
1. Der Angreifer ruft die Anwendung als anonymer Nutzer auf.
2. Für die neue Session wird ein Cookie mit einer Sessionkennung erzeugt (123).
3. Das Cookie mit der Sessionkennung wird dem Angreifer gesendet.
4. Der Angreifer entnimmt dem Cookie die Kennung und gestaltet damit einen speziellen Link. Diesen lässt er dem Opfer zukommen.
5. Das Opfer verwendet den Link, um zur Anwendung zu gelangen. Dabei meldet es sich mit seinen Daten an.
6. Die Anwendung akzeptiert die Sessionkennung (123) und ordnet diese dem korrekt angemeldeten Nutzer „Müller“ zu.
7. Auch der legitimierte Nutzer bekommt ein Cookie zugeschickt.
8. Der Angreifer kann jetzt mit seinem eigenen Cookie die Anwendung aufrufen.
9. Da in der Zwischenzeit die Sessionkennung (123) des Angreifers dem Nutzer „Müller“ zugeordnet wurde, wird der Angreifer mit dieser Kennung als Nutzer „Müller“ von der Anwendung akzeptiert werden.


Schutz:
Der Schutz vor Session-Fixation ist denkbar einfach. Man muss lediglich eine neue SessionID generieren, sodass der Angreifer die alte, von ihm generierte ID, nicht mehr benutzen kann.
Durch die funktion

wird eine neue zufällige ID generiert.


Nun meine Frage:
Wann muss eine neue ID generiert werden. Im Netz scheiden sich hier die Geister, ob vor oder erst nach der Anmeldung eine neue ID generiert werden soll.
Ich sage, das es vollkommen egal ist, was meint ihr dazu?

grüße

Hi,

weiter gehts.

Da mittlerweile so ziemlich jeder gegen XSS oder SQL-Injections geschützt ist, werden Angriffe auf Sessions immer beliebter. Sie sind mittlerweile einer der häufigsten Angriffe auf Webanwendungen.


Session Hijacking

Neben der sog. Session Fixation gibt es eine weitere beliebte Angriffsform auf Session. Das sog. Session Hijacking.

Das Session Hijacking ist eine Methode, mit der sich ein Angreifer eine SessionID aneignet. Dafür werden dem Angreifer mehrere Möglichkeiten geboten.

1. Brute Force
Brute Force ist eine Variante, mit der der Angreifer versucht, das Format der SessionID's zu erraten, indem er verschiedene Kombinationen ausprobiert, bis er eine passende ID erraten hat.

2. XSS
Der Versuch des Ausspähens der SessionID ist wohl einer der Standardangriffe über Cross-Site-Scripting. Da die meisten allerdings gegen XSS geschützt sind, wird es den Angreifer heutzutage schwer gemacht über XSS an Sessiondaten zu gelangen.

3. Fuzzing
Ähnliche der Brute Force Methode. Allerdings weiß der Angreifer hier, welchen Aufbau die bestimmte Session hat oder aus welchem Zahlenbereich die SessionID vergeben wird. Beispielsweise hat er in einem Webshop die SessionID 1234 zugewiesen bekommen und ist mit dem Username "Cracker" angemeldet. Er ändert nun die SessionID auf 1235 und hofft, einen Zugang als User "Engel" zu erhalten.

4. Logfiles durchsuchen
Einer der unwarscheinlichsten Angriffe auf eine Session, da der Angreifer zugang zu den Serverlogfiles haben muss oder sich diesen Zugang verschaffen muss. Hat er zugang erhalten, kann er nach SessionID's suchen, die über GET-Requests übertragen werden.
Da in den meisten Fällen die Serverlogfiles nich einfach für jedermann zur verfügung stehen, wird hier ofmals noch ein Hack des Webservers vorrausgesetzt um sich zugang zu verschaffen, was wesentlich mehr arbeit bedeutet und viele Script-Kiddys schlicht überfordert!

5. (Network)Sniffen
Bietet sich dem Angreifer die Möglichkeit, sich als "Man-In-The-Middle" einzuschleusen (physikalisch oder logisch) und den Netzwerkverkehr zwischen Client und Server mitzulesen (z.b über Wireshark oder what ever) ist es ein einfaches an die SessionIDs zu gelangen bzw diese zu erkennen. hierfür muss der Angreiffer die Kommunikation zwischen Server und Client über seinen Rechner leiten. Dadurch erhält er alle versendeten Pakete. Dies ist aber nur bei normalen http verbindungen sehr einfach, da die daten zwischen Client und Server unverschlüsselt übertargen werden. Wird eine verschlüsselte verbindung über https (ssl) benutzt, hat der Angreifer "keine" möglichkeit die SessionID mitzulesen bzw diese zu erkennen.


Schutz:
Es sei gesagt, einen 100% Schutz gibt es nicht. Den gibts ja generell nie...
Zusätzlich lässt sich nich verhindern, das der Angreifer anstelle seiner eigenen, eine andere SessionID sendet. Es muss also die Möglichkeit, überhaupt an eine andere gültige SessionID zu gelangen, verhindert werden.

Dazu bieten sich wieder mehrere Möglichkeiten:
1. XSS Schwachstellen schließen.
2. Sniffing durch verwendung von verschlüsselten Verbindungen unterbinden (SSL).
3. Logfiles: SessionID's sollten wenn möglich nicht mit den URL's übergeben werden. Bei Post-Request besteht keine gefahr, da diese nicht in den Logfiles gespeichert werden (werden im Request-Body übertragen)
4. Fuzzing / Brute Force: Wenn möglich sollten Sessions erst nach einem gültigen Login gestartet werden. Zusätzlich sollten SessionID's zufällig generiert werden, um eine Vorhersage zu erschweren. Zusätzlich sollte die Session nicht nur über die SessionID identifiziert werden sondern auch noch über einen Fingerabdruck des Users.Die Möglichkeit des Session Hijacking wird dadurch minimiert. Beispielsweise können der verwendete User_Agent, die ersten stellen der IP adresse (bitte nicht die gesamte IP!) oder das Datum verwendet werden. Je mehr Daten zur identifizierung verwendet werden, desto sicherer wird dei Session.

Generell sollten Sessions nur eine definierte Gültigkeitsdauer aufweisen. Zusätzlich sollte noch eine Timeoutfunktion eingebaut werden, die nache einer gewissen Zeit der inaktivität den Benutzer ausloggt und die Session vernichtet! Außerdem sollten klar erkennbar eine Logout funktion geboten werden.

Auch das "beenden" der Sessions kann sicherer gestaltet werden. Beispielsweise kann bzw sollte neben der funktion session_unset(); auch session_destroy(); verwendet werden. Wer auf nummer Sicher gehen will, kann zuerst
session_unset();
$_SESSION = array();
session_destroy();
verwenden.


Da Sessions mittlerweile sehr beliebt sind, sollte sich jeder Gedanken über die sicherheit seiner Webanwendungen machen.

Evtl könnt ihr ja Posten wie ihr euch gegen solche Angriffe absichert.

mfg
Timo

Hi Lemmi,
danke für deinen beitrag. Ich denke ich werde einen Wikibeitrag verafassen, sobald sich ein paar user dazu geäußert haben. Habe mir gedacht das wir alle vllt Lösungen zur Sicherheit erarbeiten und ich dann, für die User die noch nicht so sicher im Umgang mit PHP sind, einen Wikieintrag verfasse der auch Code schnipsel enthält.

So hat dann jeder was von diesem Thema, ob Fortgeschrittene oder Anfänger spielt dann keine Rolle mehr.

grüße
Timo