Bundesamt für Sicherheit in der Informationstechnik

M 4.401 Schutz vertraulicher Daten bei Webanwendungen

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Verantwortliche der einzelnen Anwendungen

Verantwortlich für Umsetzung: Entwickler, Administrator

Bei Webanwendungen werden Daten sowohl auf dem Server ( z. B. in einer Webanwendung) als auch auf den Clients (z. B. im Browser) gespeichert und dabei über Netze übertragen. Hierbei kann es sich um vertrauliche Bankdaten, wie Kreditkarteninformationen oder Überweisungen, handeln. Daher müssen Maßnahmen getroffen werden, damit diese Daten nicht unbefugt eingesehen oder manipuliert werden können.

Allgemeine Aspekte

Werden vertrauliche Daten durch die Webanwendung verarbeitet, übertragen oder gespeichert (server- wie auch clientseitig), sollten sie durch kryptographische Verfahren geschützt werden. Auch wenn die Webanwendung kompromittiert ist, sollten die eingesetzten kryptographischen Verfahren diese Daten weiterhin schützen.

Vertrauliche Daten einer Webanwendung sind z. B.:

  • Zugangsdaten (z. B. Benutzer, Passwort),
  • Authentisierungsdaten (z. B. Session ID ),
  • kritische Daten, die von der Webanwendung verarbeitet werden (z. B. Zahlungsinformationen oder Gesundheitsdaten).

Kryptographische Verfahren können bei der Verarbeitung, Übertragung und Speicherung dieser Daten durch die Webanwendung und den Clients verwendet werden. Sie können dabei z. B. wie folgt eingesetzt werden:

  • Verschlüsselung von Daten,
  • Sichere Speicherung von Zugangsdaten,
  • Schutz des Transportkanals.

Es ist darauf zu achten, kryptographische Algorithmen für den jeweiligen Einsatzzweck auszuwählen, die dem Stand der Technik entsprechen und keine bekannten Schwachstellen aufweisen (siehe hierzu M 2.164 Auswahl eines geeigneten kryptographischen Verfahrens ). Die kryptographischen Algorithmen sollten serverseitig umgesetzt sein.

Eine besondere Bedeutung bei der Kryptographie kommt den verwendeten Schlüsseln zu. Diese müssen je nach Einsatzgebiet über eine gewisse Mindestlänge verfügen und verschiedenen mathematischen Anforderungen (z. B. Komplexität) genügen. Zudem muss für einen entsprechend sicheren Transport beziehungsweise Austausch von Schlüsseln gesorgt werden. Gleiches gilt auch für deren Speicherung. Bei der Gestaltung einer Webanwendung sollten diese Punkte geregelt und in einem Kryptokonzept zusammengefasst werden (siehe B 1.7 Kryptokonzept ).

Für Webanwendungen mit hohem Schutzbedarf kann zusätzlich eine Absicherung der Nutzdaten erforderlich sein. Werden beispielsweise Sozialdaten mit hohen Anforderungen an die Vertraulichkeit von der Webanwendung verarbeitet, können diese Daten von der Webanwendung vor der Speicherung verschlüsselt werden. So kann sichergestellt werden, dass auch bei einem direkten Zugriff auf die Datenbank (z. B. durch Datenbankadministratoren) keine verwertbaren Daten ausgelesen werden können.

Werden vertrauliche Daten übertragen, können sie durch einen sicheren Transportkanal vor dem unbefugten Einsehen oder der Manipulation geschützt werden. Bevor vertrauliche Daten übertragen werden, sollte daher zu einer gesicherten Verbindung gewechselt werden. Auch nach der Anmeldung eines Benutzers sollten die übertragenen Daten weiterhin durch eine gesicherte Verbindung geschützt werden. Der Transportkanal wird hierzu üblicherweise durch den Einsatz von SSL / TLS abgesichert (siehe M 5.66 Clientseitige Verwendung von SSL/TLS L).

Schutz clientseitig gespeicherter Daten

Die zwischen dem Client und der Webanwendung ausgetauschten Daten können vom Client im lokalen Browsercache zwischengespeichert werden. Wenn der Browser die Daten über die Sitzungsdauer des Webanwendungsbenutzers hinaus im Cache speichert, können diese von Personen mit Zugriff auf den Rechner des Benutzers und von Skripten und Browser-Plugins ohne zusätzliche Zugriffskontrolle aus dem Cache abgerufen werden.

Das clientseitige Zwischenspeichern (Cachen) von vertraulichen Daten der Webanwendung kann durch folgende Direktiven in den HTTP -Headern der Webanwendung unterbunden werden:

  • Cache-Control: no-cache, no-store
  • Pragma: no-cache
  • Expires: -1

Da der Web-Browser üblicherweise nicht unter der Kontrolle des Betreibers der Webanwendung steht, kann somit nicht vollständig ausgeschlossen werden, dass Daten trotzdem zwischengespeichert werden. Daher kann es für Webanwendungen mit hohem Schutzbedarf zusätzlich erforderlich sein, dass der Benutzer den Browsercache während der Bedienung der Webanwendung deaktiviert oder ihn löscht, sobald er seine Tätigkeiten an der Webanwendung beendet hat. In diesem Fall kann dem Benutzer beispielsweise nach erfolgter Abmeldung ein Hinweis für das Löschen des Browsercaches angezeigt werden. Dies betrifft insbesondere Webanwendungen, die von öffentlichen IT -Systemen aus genutzt werden. Alternativ kann der Benutzer auf die Verwendung des Private Modes des Browsers hingewiesen werden, bei dem keine Daten über die Sitzung zwischengespeichert werden.

Häufig werden bei der Bedienung einer Webanwendung Daten in Cookies auf dem Client gespeichert. Bei jedem Zugriff auf die Webanwendung werden diese Cookies transparent für den Benutzer an die Webanwendung übermittelt. Dabei kann es sich auch um schützenswerte Daten wie die SessionID handeln. Der Zugriff auf Cookies mit vertraulichen Daten sollte daher so weit wie möglich eingegrenzt werden. Wenn Cookies durch die Webanwendung erstellt werden, sollten folgende Cookie-Flags gesetzt sein:

  • Domain
    Das Cookie-Flag sollte nicht gesetzt werden, denn dann werden per Default nur Anfragen der Domain beantwortet, die das Cookie gesetzt hat. Sollte es notwendig sein, dies auch anderen (Sub-)Domains zu ermöglichen, dann sollte die Domäne so weit wie möglich eingeschränkt werden, ohne die Funktionalität der Webanwendung einzuschränken (z. B. webapp.domain.tld anstatt domain.tld).
  • Path
    Das Path-Attribut beschränkt die Gültigkeit des Cookies auf einen festgelegten Pfad der Webanwendung. Auch das Path-Attribut sollte so weit wie möglich eingeschränkt werden, ohne die Funktionalität der Webanwendung einzuschränken (z. B. /webapp/ anstelle von /).
  • Secure
    Ist die Direktive Secure gesetzt, so wird das Cookie ausschließlich über verschlüsselte Kommunikationskanäle übertragen, wie z. B. über SSL/TLS.
  • HttpOnly
    Diese Direktive verhindert, dass clientseitige Skripte auf das Cookie zugreifen (z. B. JavaScript). Es ist zu beachten, dass dieses Attribut nicht von allen Browsern unterstützt wird.

Das folgende Beispiel zeigt die Anweisung zur Erstellung eines Cookies unter Verwendung genannter Direktiven:

Set-Cookie: SESSIONID=sl342kdfjslaal39skdj; path=/webapp; secure; HttpOnly

Bei der Authentisierung des Benutzers gegenüber einer Webanwendung wird gewöhnlich ein HTML-Formular verwendet, in das der Benutzername und das Passwort eingegeben werden. Wenn der Benutzer sein Passwort in das Passwortfeld eintippt, sollte es nicht im Klartext wiedergegeben, sondern durch sogenannte Wildcards ersetzt werden (z. B. Sterne oder Punkte). Hierfür muss in der Formulardefinition der Passwort-Feld-Typ ausgewählt werden (type="password").

Darüber hinaus kann der Web-Browser angewiesen werden, vertrauliche Formulardaten (z. B. den Benutzernamen und das Passwort) nicht zwischenzuspeichern und beim nächsten Aufruf des Formulars als Auswahl vorschlagen. Die Option autocomplete="Off" sollte hierfür bei der Definition des Formulars im Formularkopf gesetzt werden.

Während der Sitzung eines Benutzers an einer Webanwendung müssen in der Regel benutzerspezifische Daten gespeichert werden (z. B. die Artikel im Warenkorb). Diese Daten können dabei nicht nur serverseitig, sondern auch clientseitig in einem Cookie oder im Web-Storage des Browsers gespeichert werden. Grundsätzlich sollte vermieden werden, vertrauliche Daten an den Client zu übertragen oder auf dem Client zu speichern, da die Webanwendung keinen Einfluss auf den Schutz von clientseitig hinterlegten Daten hat. So können vom Browser auf dem Client umgesetzte Sicherheitsmechanismen zum Schutz der Daten häufig umgangen werden (z. B. durch direkten Zugriff auf das Dateisystem durch lokale Benutzer oder durch Cross-Site Scripting). Stattdessen sollten vertrauliche Daten grundsätzlich serverseitig gespeichert werden und ausschließlich das Identifikationsmerkmal des Benutzers (z. B. die SessionID) clientseitig hinterlegt sein.

Falls nicht vermieden werden kann, dass Sitzungsdaten clientseitig gespeichert werden, sollten diese Daten verschlüsselt und vor der Verarbeitung durch die Webanwendung auf Integrität geprüft werden. Damit wird sichergestellt, dass die Daten während der Übertragung nicht unbefugt eingesehen oder unbemerkt manipuliert werden können.

Darüber hinaus sollten die Daten vorzugsweise nur über den Zeitraum der Sitzung und nicht persistent gespeichert werden. Beim Web-Storage-Mechanismus sollte daher das sessionStorage-Objekt vor dem localStorage-Objekt bevorzugt werden.

Schutz serverseitig hinterlegter Daten

Sollen sich Benutzer an der Webanwendung anmelden können, müssen Zugangsdaten auf der Webanwendung gespeichert werden. Damit auch nach einer möglichen Kompromittierung der Webanwendung durch einen Angreifer die Zugangsdaten geschützt sind, dürfen sie nicht im Klartext gespeichert werden. Stattdessen sollten sie mithilfe von zeitgemäßen kryptographischen Algorithmen als salted Hashes hinterlegt werden, bei denen eine zufällige Zeichenfolge an den Klartext angehängt wird. Hierbei sollte für jedes Passwort ein unterschiedlicher, zufälliger Salt verwendet werden.

Darüber hinaus sollten die Zugangsdaten serverseitig auf einem vertrauenswürdigen IT-System (z. B. auf dem der Webanwendung) und in einem geschützten Bereich (z. B. außerhalb des Web-Root-Verzeichnisses oder in separaten Datenbanktabellen) hinterlegt sein. Die Zugangsdaten sollen nicht im Quelltext der Webanwendung (Hardcoded Passwords) gespeichert werden.

Darüber hinaus sollte ausschließlich die Webanwendung mit Schreibrechten auf die Zugangsdaten zugreifen können. Die Zugangsdaten sollten nur durch den Benutzer und über die vorgesehenen Schnittstellen und Funktionen der Webanwendung geändert werden können, sodass es Benutzern nicht möglich ist, Zugangsdaten unbefugt über z. B. den direkten Zugriff auf das Dateisystem zu lesen, zu ändern oder zu löschen.

Ruft ein Benutzer eine Webseite von der Webanwendung auf, so wird die Seite in der Regel von der Anwendung zur Laufzeit erstellt. Die aufgerufene Datei enthält Code, der von der Webanwendung vor der Auslieferung interpretiert wird und eine Webseite zurückliefert. Diese Webseite wird an den Benutzer übermittelt.

Üblicherweise werden anhand der Datei-Endung diese Dateitypen einem Interpreter oder Parser zugeordnet. Ändert sich die Datei-Endung, werden diese möglicherweise an den Benutzer übertragen, ohne vorher interpretiert zu werden. Werden derartige Dateien abgerufen, erhält der Benutzer Einsicht in die Programmlogik und vertrauliche Informationen, die gegebenenfalls im Code gespeichert sind. Dies kann beliebige Dateien betreffen, deren Datei-Endung nicht einem Interpreter oder Parser zugeordnet ist. Beispiele für anfällige Dateien sind:

  • temporäre Dateien (z. B. temp.tmp),
  • Backup Daten (z. B. backup.bak),
  • Konfigurationsdateien (z. B. config.conf),
  • Einzubindende Dateien (z. B. include.inc).

Die Dateien können vertrauliche Informationen, wie Zugangsdaten, enthalten, die hierüber bei unzureichender Zugriffsbeschränkung abgerufen werden können.

Daher sollten Dateien, die nicht für die Interpretation und den direkten Abruf durch den Benutzer vorgesehen sind, von der Webanwendung nicht ausgeliefert werden. Zusätzlich sollten die Dateisystemberechtigungen auf diese Dateien restriktiv gesetzt sein. Nicht mehr benötigte Dateien sollten zeitnah gelöscht werden (siehe auch M 4.400 Restriktive Herausgabe sicherheitsrelevanter Informationen bei Webanwendungen und Web-Services , Absatz Löschen nicht benötigter Dateien).

Prüffragen:

  • Verwendet die Webanwendung sichere, kryptographische Algorithmen zum Schutz der Daten und werden diese serverseitig auf einem vertrauenswürdigen IT-System umgesetzt?

  • Übermittelt die Webanwendung vertrauliche Daten über einen geschützten Transportkanal (z. B. SSL/TLS)?

  • Sind Direktiven in den HTTP-Headern der Webanwendung vorgesehen, die ein clientseitiges Zwischenspeichern vertraulicher Daten verhindern?

  • Setzt die Webanwendung Cookie-Flags zum Schutz der Cookies vor unbefugter Einsicht?

  • Sind Formularfelder der Webanwendung so konfiguriert, dass vertrauliche Formulardaten (z. B. das Passwort) nicht im Klartext angezeigt oder vom Browser gespeichert werden?

  • Werden Zugangsdaten der Webanwendung serverseitig mithilfe von kryptographischen Algorithmen vor unbefugtem Zugriff geschützt (Salted Hash)?

  • Wird der Abruf von Dateien unterbunden, die Quelltexte der Webanwendung enthalten?

Stand: 13. EL Stand 2013