M 4.394 Session-Management bei Webanwendungen
Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT
Verantwortlich für Umsetzung: Entwickler, Administrator
Webanwendungen verwenden in der Regel das zustandslose Protokoll HTTP zur Übertragung der Daten. Es unterstützt keine Zuordnung zusammengehörender Anfragen zu einem Benutzer wie z. B. einzelne Seitenaufrufe zur Füllung eines virtuellen Warenkorbs. Um zusammengehörende Anfragen eines Benutzers zu erkennen und einer Sitzung zuzuordnen, vergibt eine Webanwendung eine Session ID (z. B. nach erfolgreicher Anmeldung), die anschließend bei jedem Seitenaufruf übertragen wird. Wenn sich der Benutzer bei der Webanwendung angemeldet hat, ist die SessionID vergleichbar mit seinen Zugangsdaten. Die Webanwendung identifiziert mit ihr bei jedem Seitenaufruf den Benutzer und ordnet ihn einer (gegebenenfalls privilegierten) Sitzung zu. Nutzen Unbefugte die SessionID, werden sie von der Webanwendung als legitime Benutzer identifiziert und können die Anwendung im Namen des Opfers verwenden.
Das Session-Management einer Webanwendung hat zur Aufgabe, die Sitzungen zu verwalten und neue SessionIDs zu vergeben. Dabei sollten die folgenden Anforderungen und Aspekte berücksichtigt werden.
Anforderungen an die SessionID
Es ist zu beachten, dass die Gültigkeitsdauer einer SessionID (siehe auch Abschnitt Beschränkte Sitzungsdauer) deutlich kleiner sein sollte als die Zeit, die ein Angreifer zum Erraten einer SessionID benötigt. Dies kann mit einer Formel für eine Webanwendung individuell bewertet werden (siehe Formel zur Berechnung der Bewertungsgrundlage für SessionIDs in Hilfsmittel zum Baustein Webanwendung).
Die SessionID sollte mindestens folgende Anforderungen erfüllen:
- Die Session-ID muss mithilfe kryptografischer Zufallszahlengeneratoren zufällig erzeugt werden und sollte eine Entropie von mindestens 64 Bit haben, damit sie von einem potentiellen Angreifer nicht erraten werden kann. Um die Entropie der SessionID zu erhöhen, kann beispielsweise die Länge erhöht (z. B. 128 Bit) und der Zeichenraum der SessionID (z. B. alphanumerische Zeichen und Sonderzeichen) vergrößert werden. Als Richtwert sollte hierbei die Länge der SessionID mindestens die doppelte Anzahl an Bits haben wie die Anzahl an Entropie-Bits der SessionID. Demzufolge sollte die SessionID mindestens 128 Bit lang sein. Unter der Annahme, dass ein Zeichen durch 8 Bit dargestellt wird, bestünde eine solche SessionID aus mindestens 16 Zeichen (128 Bit / 8 = 16 Byte).
- Es sollten keine extern bekannten oder erratbaren Daten (z. B. RFC -Adresse, Uhrzeit) in die Berechnung der SessionID einfließen, sofern dies die Entropie nicht tolerierbar verringert.
- Unterstützt das der Webanwendung zugrunde liegende Framework die Generierung von SessionIDs, sollte vorzugsweise die Funktion des Frameworks verwendet werden. Die Funktionalität von führenden Frameworks ist in der Regel getestet und unterstützt die sichere Erzeugung von SessionIDs. Eine fehleranfällige Neuentwicklung sollte daher vermieden werden.
- Wird ein Framework zur Verwaltung und Erzeugung der SessionIDs verwendet, so ist auf eine sichere Konfiguration des Frameworks zu achten, sodass die zuvor genanten Anforderungen an die SessionID erfüllt sind.
Schutz vor unbefugtem Zugriff auf die SessionID
Die SessionID kann sowohl in der URL eines Requests (GET-Methode), im Rumpf des Requests (POST-Methode) oder als Cookie im Header des Requests übertragen werden. Wenn Daten mithilfe der GET-Methode übermittelt werden, können sie von beteiligten IT-Systemen gespeichert und dadurch von Dritten eingesehen werden (z. B. im Browser-Verlauf, auf Bildschirmfotos, Seitenkopien oder Ausdrucken). Daher sollte die SessionID nicht über die GET-Methode (also in der URL ) übertragen werden. Für Webanwendungen mit hohem Schutzbedarf ist dies nicht erlaubt. Stattdessen sollte die SessionID vorzugsweise in Cookies übertragen werden.
Erfordert die Anwendung die GET-Methode (z. B. aus Gründen der Kompatibilität mit Clients, die keine Cookies verarbeiten können), sind folgende Punkte zu beachten:
- Benutzer sollten auf die genannten Gefahren hingewiesen werden und beim Verlassen des Rechners die Sitzung beenden oder den Rechner sperren.
- Die Benutzer sollten angewiesen werden, keine gespeicherten Seiten oder Bildschirmfotos vonseiten der Webanwendung zu versenden, bei der die SessionID in der URL sichtbar ist.
- Bei Nutzung der Webanwendung über einen öffentlichen Rechner sollte eine Meldung darauf hinweisen, dass der Browser-Verlauf nach Beenden der Sitzung gelöscht werden sollte.
- Durch sehr lange SessionIDs kann das Abschreiben und das zufällige Mitlesen erschwert werden.
- Bei der Verlinkung auf externe Seiten darf die SessionID nicht übertragen werden. Dies gilt sowohl für die Übertragung in der URL als auch für das Referrer-Feld. Daher sollte bei Verlinkungen auf externe Seiten eine erzwungene Weiterleitung erfolgen, welche das Referrer-Feld bereinigt.
Zum Schutz vor unbefugtem Mitlesen der SessionID sollte nach einer erfolgreichen Anmeldung die Kommunikation über eine sichere Verbindung stattfinden (z. B. mittels SSL / TLS ; siehe M 5.66 Verwendung von TLS/SSL ). Die SessionID kann über eine ungesicherte Verbindung übertragen werden, wenn mit der bestehenden Sitzung keine zugriffsgeschützten Bereiche der Webanwendung verwendet werden können. Gewöhnlich ist der Benutzer in diesem Fall noch nicht authentisiert.
Der Zugriff auf die SessionID als Authentisierungsmerkmal sollte streng reglementiert werden. Wird die SessionID im Cookie übertragen, sollte der Zugriff auf das clientseitige Cookie nach Möglichkeit durch das Setzen folgender Flags eingeschränkt werden (für eine detaillierte Beschreibung der Cookie-Flags siehe M 4.401 Schutz vertraulicher Daten bei Webanwendungen ):
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.
Beschränkte Sitzungsdauer
Eine Webanwendung muss Benutzern die Möglichkeit geben, eine bestehende Sitzung nach ihrer Nutzung explizit zu beenden. Daher muss auf allen Webseiten, für deren Abruf eine Authentisierung des Benutzers notwendig ist, eine deutlich sichtbare Abmeldemöglichkeit bestehen. Nach erfolgter Abmeldung sollte die Sitzung vollständig beendet werden und die SessionID ihre Gültigkeit verlieren. Darüber hinaus sollte der Benutzer bei der Verwendung von Webanwendungen für folgende Verhaltensweisen sensibilisiert werden:
- Ist der Benutzer angemeldet, sollte er sich nach Abschluss der Tätigkeiten von der Webanwendung ordnungsgemäß abmelden.
- Falls beim letzten Besuch keine Abmeldung erfolgt ist, sollte der Benutzer bei dem nächsten Anmeldevorgang an der Webanwendung darauf hingewiesen werden sich zukünftig abzumelden.
Ungenutzte, bestehende Sitzungen bieten eine Angriffsfläche für Brute-Force-Angriffe auf die SessionID. Daher sollten Sitzungen nach einem Zeitintervall der Inaktivität ihre Gültigkeit verlieren (Idletime). Darüber hinaus sollte eine maximale Gültigkeits-Lebensdauer vergeben werden (Timeout), sodass auch die SessionIDs von aktiven Sitzungen eine begrenzte Gültigkeit haben. Diese sollte für die Sitzungen so gering wie möglich gewählt werden, sodass Brute-Force-Angriffe erschwert werden, wobei die Benutzbarkeit der Webanwendung hierbei nicht unnötig eingeschränkt werden sollte. Die Formel aus dem Abschnitt Anforderungen an die SessionID kann für die Ermittlung einer angemessene Gültigkeitsdauer herangezogen werden.
Treten bei der Nutzung der Webanwendung schwerwiegende Fehler auf, sollten angeforderte Aktionen abgebrochen und zusätzlich die Sitzung beendet werden. Schwerwiegende Fehler sind z. B. auftretende Ausnahmefehler (Exceptions) und erkannte Angriffsversuche. Bei einem hohen Schutzbedarf sollten noch engere Kriterien in Erwägung gezogen werden, die zur Invalidierung der Sitzung führen (z. B. ungültige Eingaben, Aufruf fehlender Seiten).
Bei der Invalidierung sollten die Sitzungsdaten server- und clientseitig vollständig gelöscht werden, sodass die Sitzung serverseitig nicht weiter akzeptiert wird und clientseitig keine Informationen über zuvor aufgebaute Sitzungen verbleiben. Dies kann z. B. durch Löschen des Cookies mit der SessionID erfolgen.
Darüber hinaus können mehrere parallele Sitzungen unter dem gleichen Benutzerkonto verhindert werden. Eine bestehende Sitzung kann bei erneuter Anmeldung invalidiert werden, sodass nur die neue Sitzung gültig bleibt. Alternativ ist es beispielsweise möglich die erste Sitzung über einen begrenzten Zeitraum (z. B. 15 Minuten) aufrechtzuerhalten, bevor sie invalidiert wird. Dabei sollte dem Benutzer bei der Anmeldung über eine parallele, zweite Sitzung eine Meldung über die ablaufende, erste Sitzung eingeblendet werden. Auf diese Weise können noch bestehende, aber nicht mehr verwendete Sitzungen nach erneuter Anmeldung nicht oder nur eingeschränkt unbefugt von Dritten genutzt werden.
Zum Schutz vor Session-Fixation-Angriffen sollte nach erfolgter Anmeldung eine bereits bestehende SessionID durch eine neue ersetzt werden.
Ebenso sollte nach einem Wechsel von einem ungesicherten Kommunikationskanal ( HTTP ) auf einen gesicherten Kommunikationskanal ( HTTPS ) eine neue SessionID vergeben werden, da die SessionID bei der Übertragung über einen ungesicherten Kanal mitgelesen worden sein könnte.
Schutz der Sitzungsdaten
Zum Schutz der Vertraulichkeit sollten die anfallenden Sitzungsdaten (z. B. Warenkorb) ausschließlich serverseitig auf einem vertrauenswürdigen IT -System gespeichert werden. Darüber hinaus sollten die Daten vor unbefugtem Zugriff von anderen Benutzern durch eine Zugriffskontrolle geschützt werden. Falls die Webanwendung eine clientseitige Speicherung der Sitzungsdaten erfordert, sollte ebenfalls M 4.401 Schutz vertraulicher Daten bei Webanwendungen für die Speicherung von Daten auf dem Client beachtet werden.
Zuordnung einer Sitzung anhand zusätzlicher Attribute
Neben der SessionID können weitere Merkmale zur Zuordnung zwischen Benutzer und Sitzung verwendet werden (z. B. die IP-Adresse). Hierdurch kann die unbefugte Nutzung bestehender Sitzungen erschwert werden, da ein Angreifer für eine erfolgreiche Übernahme der Sitzung neben einer gültigen SessionID die zusätzlichen Merkmale kennen muss. Die Verwendung von zusätzlichen Attributen zur Zuordnung einer Sitzung ist zumindest bei Webanwendungen mit hohem Schutzbedarf zu berücksichtigen.
Wird die IP-Adresse als zusätzliches Merkmal für die Sitzungszuordnung verwendet, so ist diese serverseitig zu speichern und zu prüfen. Wechselt die IP-Adresse im Laufe einer Sitzung, so sollte dies bei Anwendungen mit hohem Schutzbedarf als Angriffsversuch gewertet und demzufolge die Sitzung invalidiert werden. Dabei ist jedoch zu berücksichtigen, dass die IP-Adresse nicht immer einem Nutzer eindeutig zugeordnet werden kann. Erfolgt die Verbindung einiger Benutzer der Webanwendung über einen Proxy mit gleicher (z. B. Reverse-Proxy) oder wechselnder IP-Adresse (z. B. wechselnde, ausgehende Proxys), besteht die Gefahr, dass die IP-Adressen dieser Nutzer nicht eindeutig einer Sitzung zugeordnet werden können. Es sollte somit bedacht werden, dass einige Benutzer die Webanwendung möglicherweise nur eingeschränkt oder gar nicht nutzen können.
Wenn der Referrer als Identitätsmerkmal verwendet wird, kann auf einen festen Teil des Referrer-Pfades geprüft werden, der für alle Zugriffe identisch bleibt (z. B. die Domäne der Webanwendung). Die Benutzer müssen demnach eine Webseite der Webanwendung im Referrer vorweisen. Hierbei ist zu berücksichtigen, dass einige Browser eine Deaktivierung der Referrer-Übermittlung erlauben und Content-Filter dieses Feld gegebenenfalls filtern.
Die Identitätsmerkmale können zum Schutz vor unbefugter Nutzung der Sitzung auf mehrere Eigenschaften des HTTP-Headers verteilt werden. Denkbar sind z. B. HTTP-Header-Informationen wie
- die Browsertypenbezeichnung (User-Agent-Header),
- unterstützte Formate und Sprachen des Clients (Accept- und Accept-Language-Header) und
- der Referrer (Referrer-Header).
Aufgrund der teilweise geringen Variationsbreite der genannten Merkmale des HTTP-Headers ist der zusätzlich erreichte Schutz begrenzt. Dagegen erhöht sich der Umsetzungsaufwand und unter Umständen die Komplexität bei der Fehlersuche. Aus diesem Grund sollte im Einzelfall abgewogen werden, ob der zusätzlich erreichte Schutz den Umsetzungsaufwand rechtfertigt.
Prüffragen:
- Hat die SessionID der Webanwendung eine ausreichende Entropie, um dem Erraten der SessionID (z. B. durch einen Brute-Force-Angriff) standzuhalten?
- Wird die Vertraulichkeit der SessionID bei der Übertragung und clientseitigen Speicherung ausreichend geschützt?
- Hat die Sitzung eine begrenzte Gültigkeit (Timeout) und ist diese gemessen an den Anforderungen zur Nutzung der Webanwendung möglichst kurz gewählt worden?
- Erfolgt ein Wechsel der SessionID nach erfolgreicher Authentisierung?
- Werden alle Sitzungsdaten (sowohl server- als auch clientseitig) bei einer Webanwendung nach der Invalidierung der Sitzung ungültig und gelöscht?