Bundesamt für Sicherheit in der Informationstechnik

M 4.394 Session-Management bei Webanwendungen und Web-Services

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, Entwickler

Webanwendungen und Web-Services verwenden in der Regel das zustandslose Protokoll HTTP zur Übertragung der Daten. Es unterstützt keine Zuordnung zusammengehörender Anfragen zu einem Benutzer wie zum Beispiel einzelne Seitenaufrufe zur Füllung eines virtuellen Warenkorbs. Um zusammengehörende Anfragen eines Benutzers zu erkennen und einer Sitzung zuzuordnen, wird eine Session-ID (zum Beispiel nach erfolgreicher Anmeldung) vergeben, die anschließend bei jedem Seitenaufruf, oder bei jeder Interaktion mit dem Web-Service, übertragen wird. Die Session-ID wird typischerweise von der Webanwendung oder dem Web-Service selbst erzeugt. Verwendet ein Web-Service den Standard WS-SecureConversation, kann der Security Context, und damit auch der Identifikator für die Sitzung, auch von einem dedizierten Security Token Service erzeugt werden.

Wenn sich der Benutzer bei der Webanwendung oder dem Web-Service angemeldet hat, ist die Session-ID vergleichbar mit seinen Zugangsdaten. Die Webanwendung identifiziert mit ihr bei jedem Seiten- oder Dienstaufruf den Benutzer und ordnet ihn einer (gegebenenfalls privilegierten) Sitzung zu. Nutzen Unbefugte die Session-ID , werden sie als legitime Benutzer identifiziert und können die Anwendung oder den Dienst im Namen des Opfers verwenden.

Das Session-Management einer Webanwendung oder eines Web-Service hat zur Aufgabe, die Sitzungen zu verwalten und neue Session-IDs zu vergeben. Dabei sollten die folgenden Anforderungen und Aspekte berücksichtigt werden.

Anforderungen an die Session-ID

Es ist zu beachten, dass die Gültigkeitsdauer einer Session-ID (siehe auch Abschnitt Beschränkte Sitzungsdauer) deutlich kleiner sein sollte als die Zeit, die ein Angreifer zum Erraten einer Session-ID benötigt. Dies kann mit einer Formel für eine Webanwendung oder einen Web-Service individuell bewertet werden (siehe Formel zur Berechnung der Bewertungsgrundlage für Session-IDs in Hilfsmittel zum Baustein Webanwendung).

Die Session-ID 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 Session-ID zu erhöhen, kann beispielsweise die Länge erhöht (zum Beispiel 128 Bit) und der Zeichenraum der Session-ID (zum Beispiel alphanumerische Zeichen und Sonderzeichen) vergrößert werden. Als Richtwert sollte hierbei die Länge der Session-ID mindestens die doppelte Anzahl an Bits haben wie die Anzahl an Entropie-Bits der Session-ID . Demzufolge sollte die Session-ID mindestens 128 Bit lang sein. Unter der Annahme, dass ein Zeichen durch 8 Bit dargestellt wird, bestünde eine solche Session-ID aus mindestens 16 Zeichen (128 Bit / 8 = 16 Byte).
  • Es sollten keine extern bekannten oder erratbaren Daten (zum Beispiel RFC -Adresse, Uhrzeit) in die Berechnung der Session-ID einfließen, sofern dies die Entropie nicht tolerierbar verringert.
  • Unterstützt das der Webanwendung zugrunde liegende Framework die Generierung von Session-ID s, 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 Session-ID s. Eine fehleranfällige Neuentwicklung sollte daher vermieden werden.
  • Wird ein Framework zur Verwaltung und Erzeugung der Session-ID s verwendet, so ist auf eine sichere Konfiguration des Frameworks zu achten, sodass die zuvor genanten Anforderungen an die Session-ID erfüllt sind.

Schutz vor unbefugtem Zugriff auf die Session-ID

Die Session-ID kann sowohl in der URL eines Requests (GET-Methode), im Rumpf des Requests (POST-Methode) oder als Cookie im Header des Requests übertragen werden. Wird bei Web-Services der Standard WS-SecureConversation eingesetzt, so ist die Session-ID Teil des XML-Elements wsc:SecurityContextToken, welches innerhalb der SOAP-Header übertragen wird.

Wenn Daten mithilfe der GET-Methode übermittelt werden, können sie von beteiligten IT-Systemen gespeichert und dadurch von Dritten eingesehen werden (zum Beispiel im Browser-Verlauf, auf Bildschirmfotos, Seitenkopien oder Ausdrucken). Daher sollte die Session-ID nicht über die GET-Methode (also in der URL ) übertragen werden. Für Webanwendungen oder Web-Services mit hohem Schutzbedarf ist dies nicht erlaubt. Stattdessen sollte die Session-ID vorzugsweise in Cookies übertragen werden.

Erfordert die Anwendung die GET-Methode (zum Beispiel 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 von Seiten der Webanwendung zu versenden, bei der die Session-ID 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 Session-ID s kann das Abschreiben und das zufällige Mitlesen erschwert werden.
  • Bei der Verlinkung auf externe Seiten darf die Session-ID 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 Session-ID sollte nach einer erfolgreichen Anmeldung die Kommunikation über eine sichere Verbindung stattfinden. Dies kann über eine Transportsicherung, beispielsweise mittels SSL / TLS (siehe M 5.66 Clientseitige Verwendung von SSL/TLS ) oder mittels WS-SecureConversation realisiert werden. Die Session-ID 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 Session-ID als Authentisierungsmerkmal sollte streng reglementiert werden. Wird die Session-ID in einem Cookie übertragen, sollte der clientseitige Zugriff auf diesen 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 (zum Beispiel /webapp/),
  • Secure und
  • HttpOnly.

Beschränkte Sitzungsdauer

Eine Webanwendung oder ein Web-Service 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. Bei der Verwendung von WS-SecureConversation sollte der Security Context einer Sitzung nach der Nutzung des Dienstes explizit durch das Senden einer Nachricht "WS-Trust Cancel" invalidiert werden. Nach erfolgter Abmeldung sollte die Sitzung vollständig beendet werden und die Session-ID ihre Gültigkeit verlieren. Darüber hinaus sollte der Benutzer bei der Verwendung von Webanwendungen und Web-Services 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 Session-ID. 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 Session-ID s 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 Session-ID kann für die Ermittlung einer angemessenen Gültigkeitsdauer herangezogen werden.

Treten bei der Nutzung der Webanwendung oder des Web-Service schwerwiegende Fehler auf, sollten angeforderte Aktionen abgebrochen und zusätzlich die Sitzung beendet werden. Schwerwiegende Fehler sind zum Beispiel 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 (zum Beispiel 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 zum Beispiel durch Löschen des Cookies mit der Session-ID 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 (zum Beispiel 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 Session-ID durch eine neue ersetzt werden.

Ebenso sollte nach einem Wechsel von einem ungesicherten Kommunikationskanal ( HTTP ) auf einen gesicherten Kommunikationskanal ( HTTPS ) eine neue Session-ID vergeben werden, da die Session-ID bei der Übertragung über einen ungesicherten Kanal mitgelesen worden sein könnte.

Schutz der Sitzungsdaten

Zum Schutz der Vertraulichkeit sollten die anfallenden Sitzungsdaten (zum Beispiel 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 oder der Web-Service 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 Session-ID können weitere Merkmale zur Zuordnung zwischen Benutzer und Sitzung verwendet werden (zum Beispiel 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 Session-ID 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 Benutzer eindeutig zugeordnet werden kann. Erfolgt die Verbindung einiger Benutzer der Webanwendung über einen Proxy mit gleicher (zum Beispiel Reverse-Proxy) oder wechselnder IP-Adresse (zum Beispiel wechselnde, ausgehende Proxys), besteht die Gefahr, dass die IP-Adressen dieser Benutzer 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 (zum Beispiel 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 oder benutzerseitige Manipulation 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 zum Beispiel 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.

Eigenimplementierungen vermeiden

Kann für die Sitzungsverwaltung einer Web-Anwendung oder eines Web-Service auf eine erprobte Implementierung in einem Framework oder einen verbreiteten Standard (wie WS-SecureConversation) zurückgegriffen werden, so ist dies gegenüber einer Eigenimplementierung in jedem Fall zu bevorzugen, da sich Eigenimplementierungen dieser sicherheitskritischen, komplexen Funktion sehr häufig als angreifbar erweisen.

Prüffragen:

  • Hat die Session-ID der Webanwendung beziehungsweise des Web-Service eine ausreichende Entropie, um dem Erraten der Session-ID (zum Beispiel durch einen Brute-Force-Angriff) standzuhalten?

  • Wird die Vertraulichkeit der Session-ID 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 oder des Web-Service möglichst kurz gewählt worden?

  • Erfolgt ein Wechsel der Session-ID nach erfolgreicher Authentisierung?

  • Werden alle Sitzungsdaten (sowohl server- als auch clientseitig) nach der Invalidierung der Sitzung ungültig und gelöscht?

  • Kommt für die Sitzungsverwaltung eine erprobte Implementierung oder ein verbreiteter Standard zum Einsatz?

Stand: 14. EL Stand 2014