Applikationsschutz per Kryptographie

Die Kryptografie hat in den vergangenen Jahren keine für den Endbenutzer nützlichen relevanten Fortschritte gemacht – im Bereich der Angriffe hingegen gibt es einige neue Möglichkeiten, Verfahren zu brechen, die einige Jahre zuvor noch als sicher galten. Am bekanntesten sind sicherlich die Angriffe auf das SHA1-Prüfsummenverfahren im Sommer 2006, das inzwischen als unsicher gilt und deshalb in der Entwicklung von Anwendungen nicht mehr verwendet werden sollte.
Trotzdem bietet die Kryptografie einen grossen Fundus an Verfahren, die – wenn sie korrekt und angemessen eingesetzt werden – als ausreichend sicher für beliebige Anwendungen gelten dürfen.

Kryptografie

Auch wenn sich Kryptografie im eigentlichen Sinne mit der Verschlüsselung von Daten beschäftigt, gibt es noch zwei weitere Anwendungsfälle: das Hashen von Daten, um deren Authentizität sicherzustellen, sowie das Signieren von Daten, um deren Urheber ermitteln zu können.


Das Prinzip, das diesen drei Varianten zugrunde liegt, ist jedoch fast immer das gleiche: Die Ursprungsdaten, die in der Regel als Klartext bezeichnet werden, werden mit einem (geheimen) Schlüssel verarbeitet, woraus sich der Geheimtext ergibt. Diesen kann man mit einem weiteren (geheimen) Schlüssel wieder in den Klartext zurückverwandeln. Die Sicherheit einer Verschlüsselung steht und fällt dabei durch zwei Faktoren: zum einen mit der Sicherheit des Verfahrens an sich, zum anderen mit der Sicherheit der verwendeten Schlüssel.
Bei den Verschlüsselungsverfahren wiederum wird zwischen zwei Ansätzen unterschieden – den symmetrischen und den asymmetrischen Verfahren. Der Unterschied liegt darin, dass bei den symmetrischen Verfahren der zur Verschlüsselung verwendete Schlüssel auch zur Entschlüsselung genutzt wird, bei den asymmetrischen Verfahren hingegen werden zwei verschiedene Schlüssel verwendet.

Einer dieser beiden Schlüssel ist öffentlich bekannt und dient der Verschlüsselung des Klartextes. Der dadurch entstandene Geheimtext kann dann nur noch mit dem zweiten Schlüssel, der geheim ist, entschlüsselt werden. Da bei diesem Verfahren pro Teilnehmer nur jeweils zwei Schlüssel benötigt werden, nämlich ein öffentlicher und ein privater, ist die Verwaltung der Schlüssel bei asymmetrischen Verfahren deutlich einfacher als bei symmetrischen.
Allerdings müssen diese Schlüssel – insbesondere der private – eine gewisse Komplexität aufweisen, damit sie als sicher gelten können. Die Basis für den privaten Schlüssel stellen zwei sehr grosse Primzahlen, die miteinander multipliziert werden, wobei dieses Produkt den öffentlichen Schlüssel darstellt. Da diese Multiplikation sehr einfach durchzuführen ist, die zugehörige Faktorisierung aber nicht, gelten diese Schlüssel bei ausreichend grossen Primzahlen als sicher. Populäre asymmetrische Verfahren sind beispielsweise RSA, Rabin und Elgamal.


Die Nachteile asymmetrischer Verschlüsselung sollen allerdings nicht verschwiegen werden. Zum einen sind sie aufgrund der notwendigen umfangreichen mathematischen Operationen ausgesprochen langsam, zum anderen kann es umständlich sein, eine Nachricht an mehrere Empfänger zu versenden, da sie für jeden Empfänger einzeln mit dessen öffentlichem Schlüssel verschlüsselt werden müsste.


Ausserdem basiert die Sicherheit asymmetrischer Verfahren auf der Annahme, dass es mathematisch nicht leicht möglich ist, ein Produkt wieder in seine Primfaktoren zu zerlegen. Sofern es jemandem gelingen sollte, ein solches Verfahren zu finden, sind sämtliche asymmetrischen Verfahren schlagartig als unsicher anzusehen.
Schliesslich sind asymmetrische Verfahren auch anfällig für sogenannte Man-in-the-middle-Attacken, bei denen sich ein Angreifer zwischen Sender und Empfänger begibt und dem Sender vortäuscht, mit dem wirklichen Empfänger zu kommunizieren. Der Sender verschlüsselt seine Nachricht also statt mit dem öffentlichen Schlüssel des Empfängers mit dem des Angreifers, der die Daten lesen und sie anschliessend korrekt verschlüsselt an den wahren Empfänger weiterleiten kann.


Trotz all dem sind die genannten Verfahren für die meisten Anwendungen ausreichend sicher und sämtlichen selbstentwickelten Verfahren vorzuziehen – auch wenn man in der Praxis leider immer wieder auf solche Verfahren trifft. Die genannten Verfahren sind zum einen jahrelang erprobt, zum anderen ist der Grad ihrer Sicherheit mathematisch bewiesen. Selbstentwickelte Verfahren erreichen diesen Grad an Sicherheit in der Regel nicht, weshalb sich der Aufwand in deren Entwicklung nur selten lohnen dürfte.


Zudem liegen die asymmetrischen Verfahren offen, das heisst, obwohl der Angreifer den Algorithmus kennt, ist es mathematisch (fast) unmöglich, diese Verfahren zu knacken. Selbstgeschriebene Algorithmen werden häufig geheim gehalten, was als «Security by obscurity» bezeichnet wird, wodurch eine vermeintlich höhere Sicherheit erreicht wird, was allerdings nicht der Fall ist. Zusammengefasst lässt sich also sagen:
➤ Verwenden Sie kryptografische Verfahren, die allgemein bekannt und erwiesenermassen sicher sind, statt eigene zu implementieren.

Sitzungsverwaltung

Die beste Verschlüsselung nützt nichts, wenn es einem Angreifer gelingt, die Sitzung eines legitimen Benutzers zu übernehmen. Häufig findet man entsprechende Möglichkeiten in einfacheren Webshops, in denen die Identität eines Benutzers beispielsweise nur über dessen Session-ID ermittelt wird.


Ein Angreifer kann in einem solchen Fall versuchen, Session-IDs zu erraten, oder einen legitimen Benutzer dazu bringen, seine Session-ID offenzulegen, indem er beispielsweise die URL der Seite, auf der er sich gegenwärtig befindet, weitergibt – wobei diese die Session-ID enthält. Dies kann bereits in einem harmlosen Kontext geschehen, wenn beispielsweise der legitime Benutzer einen Link auf ein Produkt weitergeben will, er allerdings zugleich angemeldet ist.
Neben aufmerksamen Benutzern ist der einzige Schutz gegen Sitzungsübernahmen ein Mechanismus auf dem Webserver, der sicherstellt, dass eine Session zeitgleich nur von einem Client genutzt werden kann, indem beispielsweise zu jeder Session die zugehörige IP gespeichert und bei jedem Zugriff verglichen wird. Die Regel lautet also:




- Verhindern Sie, dass eine Session zeitgleich von mehreren Clients genutzt werden kann.
Neben einer Sitzungsübernahme, die quasi synchron zur legitimen Benutzung stattfindet, kann ein Angreifer auch versuchen, eine Sitzung erneut ablaufen zu lassen, was als «Sitzungs-Replay» bezeichnet wird. Ein häufig eingesetztes Verfahren hierfür ist, das Session-Cookie eines Benutzers beispielsweise per Cross-Site-Scripting (XSS) oder durch einen Lauschangriff auf das Netzwerk zu ermitteln und dieses dann später selbst weiterzuverwenden. Auch hier hilft nur, Sessions zum einen an die IP zu binden, zum anderen Anfragen eine fortlaufende Nummer zuzuordnen, so dass die gleiche Anfrage nicht mehrfach gestellt werden kann. Die Regel lautet hierfür demnach:



- Verhindern Sie, dass Anfragen einer Session mehrfach und von verschiedenen Clients ausgeführt werden können.
Auch im Zusammenhang mit der Sitzungsverwaltung können Man-in-the-middle-Angriffe durchgeführt werden. Hierbei wird dem Benutzer vom Angreifer vorgespiegelt, er würde mit dem eigentlichen Server kommunizieren. Statt dessen fängt der Angreifer die Daten ab, leitet diese seinerseits an den Server weiter und sendet die erhaltenen Antworten wiederum an den Benutzer. Eine Verschlüsselung der Verbindung ist zwar hilfreich, da aber auch die Verschlüsselung gegen solche Angriffe nicht gefeit ist, ist hierbei der Einsatz von vertrauenswürdigen Zertifikaten ratsam.



- Setzen Sie nur vertrauenswürdige Zertifikate ein, die von entsprechenden Trust-Centern ausgestellt wurden.

Vertrauliche Daten

Ein weiterer Angriffspunkt, der mit der Verschlüsselung zusammenhängt, ist das Speichern sensitiver Daten. Werden beispielsweise Kennwörter im Klartext gespeichert, reicht es aus, wenn die zugehörige Datenbank kompromittiert wird, um das ganze System zu kompromittieren. Um sich gegen solche Angriffe zu schützen, bietet es sich an, vertrauliche Daten verschlüsselt zu speichern.
Zu beachten ist allerdings, dass verschlüsselte Daten nicht mehr effizient durchsucht werden können, so dass der Zugriff unter Umständen nur äusserst langsam erfolgen kann. Für Kennwörter bietet sich dieses Verfahren allerdings an, indem nur der verschlüsselte Fingerabdruck gespeichert wird. Gibt ein Benutzer sein Kennwort ein, wird auch von diesem der verschlüsselte Fingerabdruck ermittelt und mit dem gespeicherten verglichen. Auf diese Art muss das Klartext-Kennwort nicht übertragen werden.



- Speichern Sie sensitive Daten gegebenenfalls verschlüsselt. Im Falle von Kennwörtern nutzen Sie die Möglichkeit, lediglich einen Fingerabdruck abzulegen.




So verhindern Sie auch, dass Kennwörter durch Abhören des Netzwerks in falsche Hände fallen. Um das Abhören des Netzwerks generell zu verhindern, bietet sich an, sämtlichen Datentransfer zu verschlüsseln.
Schliesslich muss noch verhindert werden, dass Daten manipuliert werden. Dazu bietet es sich an, die schützenswerten Daten mit einer Prüfsumme zu versehen und diese zu signieren. Sendet der Benutzer diese Daten beispielsweise im Rahmen eines Postback einer Webseite an die Webanwendung zurück, kann der Server die Daten zum einen erneut mit einer Prüfsumme versehen und die beiden Prüfsummen anschliessend vergleichen, zum anderen kann er die Authentizität der ursprünglichen Prüfsumme anhand der digitalen Signatur sicherstellen.




- Versehen Sie Daten, die vom Server an den Client und von diesem wieder zurückgesendet werden, mit einer Prüfsumme und signieren Sie diese.




Kennwort-Speicherung per Hash

Fazit

Um die Sicherheit einer Webanwendung und speziell ihrer Daten sicherzustellen, bieten sich Verschlüsselung, Prüfsummen und digitale Signaturen an. Dabei ist es allerdings wichtig, auf die Auswahl der verwendeten Verfahren zu achten, um sich böse Überraschungen zu ersparen. Insgesamt lassen sich alle Überlegungen zu dieser Thematik in zwei Stichpunkte zusammenfassen:



- Wenden Sie erprobte Verfahren an, deren Sicherheit bewiesen ist, statt eigene zu implementieren.




- Verlassen Sie sich niemals auf eine Sicherheit, die lediglich durch das Verbergen von Implementierungsdetails entsteht («Security by obscurity»).