IT-Grundschutz-Kompendium – Februar 2020
Dieses Dokument ist Teil der Anfrage „Sicherheit des Bürgerportals“
APP.3: Netzbasierte Dienste APP.3.1 deckt. Um diese Fehler nachträglich zu beheben, muss oft der Quellcode der Webanwendung aufwendig geprüft und wieder korrigiert werden. Dadurch können die Entwicklungskosten deutlich zunehmen. Im Fall von grundle- genden architektonischen Fehlern muss die Webanwendung eventuell sogar komplett neu entwickelt werden. Gibt es darüber hinaus keine Vorgaben, um Sicherheitsmechanismen umzusetzen, werden die zu verarbeitenden Daten möglicherweise nicht ausreichend geschützt. 2.2 Umgehung der Autorisierung bei Webanwendungen Angreifer versuchen häufig, auf Funktionen oder Daten von Webanwendungen zuzugreifen, die nur für eine ein- geschränkte Benutzergruppe verfügbar sind. Ist die Autorisierung fehlerhaft umgesetzt, kann ein Angreifer unter Umständen die Berechtigungen eines anderen Benutzers mit umfangreicheren Rechten erlangen und somit auf ge- schützte Bereiche und Daten zugreifen. Das geschieht üblicherweise, indem ein Angreifer seine Eingaben gezielt manipuliert. 2.3 Unzureichende Eingabevalidierung und Ausgabekodierung Verarbeitet eine Webanwendung ungeprüfte Eingangsdaten, die von einem Angreifer manipuliert wurden, kön- nen möglicherweise Schutzmechanismen umgangen werden. Auch die Ausgabedaten der Webanwendung wer- den entweder direkt an den Webbrowser des Benutzers, die aufrufende Anwendung oder an nachgelagerte Sys- teme übermittelt. Werden diese Daten vor der Ausgabe nicht ausreichend kodiert, könnten sie Schadcode enthal- ten, der auf den Zielsystemen interpretiert oder ausgeführt wird. 2.4 Fehlende oder mangelhafte Fehlerbehandlung durch Webanwendungen Treten Fehler während des Betriebs einer Webanwendung auf, kann das z. B. die Verfügbarkeit der Webanwen- dung einschränken, bis sie etwa nicht mehr erreichbar ist. So werden eventuell Aktionen unvollständig durchge- führt, zwischengespeicherte Aktionen und Daten gehen verloren oder Sicherheitsmechanismen fallen aus. Werden Fehler nicht korrekt behandelt, kann sowohl der Betrieb als auch der Schutz der Funktionen und Daten beeinträch- tigt werden. 2.5 Unzureichende Protokollierung von sicherheitsrelevanten Ereignissen Werden sicherheitsrelevante Ereignisse von der Webanwendung unzureichend protokolliert, können diese unter Umständen zu einem späteren Zeitpunkt nicht nachvollzogen werden. Somit kann auch die Ursache nicht mehr ermittelt werden. Kritische Fehler und Angriffe, wie beispielsweise unbefugte Konfigurationsänderungen an der Webanwendung, bleiben dann möglicherweise unbemerkt. Eine unzureichende Protokollierung erschwert es auch, Schwachstellen zu erkennen und zu beheben. 2.6 Offenlegung sicherheitsrelevanter Informationen bei Webanwendungen Webseiten und Daten, die von einer Webanwendung generiert und ausgeliefert werden, können Informationen zu den Hintergrundsystemen enthalten, z. B. Angaben zu Datenbanken oder Versionsständen von Frameworks. Diese Informationen können es einem Angreifer erleichtern, gezielte Angriffe auf die Webanwendung durchzufüh- ren. 2.7 Missbrauch einer Webanwendung durch automatisierte Nutzung Wenn ein Angreifer Funktionen einer Webanwendung automatisiert nutzt, kann er zahlreiche Vorgänge in kurzer Zeit ausführen. Diese auf Wiederholung basierenden Angriffe gegen die Webanwendung sind besonders effizient. Mithilfe eines wiederholt durchgeführten Login-Prozesses kann der Angreifer z. B. versuchen, gültige Kombinatio- nen aus Benutzernamen und Passwort zu ermitteln (Brute-Force) oder Listen mit gültigen Benutzernamen zu erzeu- gen (Enumeration). Darüber hinaus kann das wiederholte Aufrufen von ressourcenintensiven Funktionen, wie z. B. komplexe Datenbankabfragen, für Denial-of-Service-Angriffe auf Anwendungsebene missbraucht werden. 2.8 Unzureichendes Session-Management von Webanwendungen Wenn es einem Angreifer aufgrund eines unzureichenden Session-Managements gelingt, die Session-ID eines be- rechtigten Benutzers zu ermitteln, kann er damit unter Umständen auf geschützte Funktionen und Ressourcen der Webanwendung zugreifen. Ein Beispiel für eine solche Angriffsform ist der Session-Fixation-Angriff. Dabei lässt sich 2 IT-Grundschutz-Kompendium: Stand Februar 2020
APP.3.1 APP.3: Netzbasierte Dienste ein Angreifer zunächst eine Session-ID von der Webanwendung zuweisen und übermittelt diese ID an einen legiti- men Benutzer, zum Beispiel über einen Link in einer E-Mail. Wenn der Benutzer diesem Link folgt und sich danach gegenüber der Webanwendung mit der vom Angreifer übermittelten Session-ID authentisiert, kann der Angreifer die Anwendung anschließend mit der ihm bekannten Session-ID verwenden. Auf diese Weise ist es ihm möglich, im Sicherheitskontext des angegriffenen Benutzers auf die Webanwendung zuzugreifen und so eventuell geschützte Funktionen zu nutzen. 3 Anforderungen Im Folgenden sind spezifische Anforderungen für den Baustein APP.3.1 Webanwendungen aufgeführt. Grundsätz- lich ist der IT-Betrieb für die Erfüllung der Anforderungen zuständig. Der Informationssicherheitsbeauftragte (ISB) ist bei strategischen Entscheidungen stets einzubeziehen. Außerdem ist der ISB dafür zuständig, dass alle Anforde- rungen gemäß dem festgelegten Sicherheitskonzept erfüllt und überprüft werden. Zusätzlich kann es noch andere Rollen geben, die weitere Zuständigkeiten bei der Umsetzung von Anforderungen haben. Diese sind dann jeweils explizit in eckigen Klammern in der Überschrift der jeweiligen Anforderungen aufgeführt. Grundsätzlich zuständig IT-Betrieb Weitere Zuständigkeiten Beschaffer, Entwickler 3.1 Basis-Anforderungen Die folgenden Anforderungen MÜSSEN für den Baustein APP.3.1 Webanwendungen vorrangig erfüllt werden: APP.3.1.A1 Authentisierung bei Webanwendungen [Entwickler] (B) Der IT-Betrieb und die Entwickler von Webanwendungen MÜSSEN sicherstellen, dass sich Benutzer gegenüber der Anwendung geeignet authentisieren, wenn diese auf geschützte Ressourcen zugreifen wollen. Dafür MUSS eine geeignete Authentisierungsmethode ausgewählt und der Auswahlprozess dokumentiert werden. Die Zugangsda- ten MÜSSEN angemessen geschützt werden. Es MUSS eine zentrale Authentisierungskomponente verwendet werden, die möglichst mit etablierten Standard- komponenten umgesetzt wurde. Die Komponente MUSS die Benutzer dazu zwingen, sichere Passwörter gemäß einer Passwort-Richtlinie zu benutzen. Speichert eine Webanwendung Authentisierungsdaten auf einem Client, MUSS der Benutzer explizit zustimmen („Opt-In“) und auf die Risiken der Funktion hingewiesen werden. In der Webanwendung MÜSSEN Grenzwerte für fehlgeschlagene Anmeldeversuche definiert sein. Alle angebote- nen Authentisierungsverfahren der Webanwendung MÜSSEN das gleiche Sicherheitsniveau aufweisen. Zudem MÜSSEN Benutzer sofort informiert werden, wenn ihr Passwort zurückgesetzt wurde. APP.3.1.A2 Zugriffskontrolle bei Webanwendungen [Entwickler] (B) Es MUSS durch die Entwickler einer Webanwendung mittels einer Autorisierungskomponente sichergestellt wer- den, dass Benutzer nur Aktionen durchführen können, zu denen sie berechtigt sind. Jeder Zugriff auf geschützte Inhalte und Funktionen MUSS kontrolliert werden, bevor er ausgeführt wird. Sollte es nicht möglich sein, Zugriffs- rechte zuzuweisen, MUSS dafür ein zusätzliches Sicherheitsprodukt eingesetzt werden. Es MÜSSEN alle von der Webanwendung verwalteten Ressourcen von der Autorisierungskomponente berücksich- tigt werden. Die Benutzer MÜSSEN serverseitig und zentral auf einem vertrauenswürdigen IT-System autorisiert werden. Ist die Zugriffskontrolle fehlerhaft, MÜSSEN Zugriffe abgelehnt werden. Auch MUSS es eine Zugriffskont- rolle bei URL-Aufrufen und Objekt-Referenzen geben. Ebenso MUSS der Zugriff auf Dateien durch die Benutzer mit restriktiven Dateisystemberechtigungen beschränkt werden. Es MUSS zudem ein sicherer Umgang mit temporären Dateien vorgesehen werden. APP.3.1.A3 Sicheres Session-Management [Entwickler] (B) Entwickler einer Webanwendung MÜSSEN sicherstellen, dass Session-IDs geeignet geschützt werden. Session-IDs MÜSSEN zufällig und mit ausreichender Entropie erzeugt werden. Falls das Framework der Webanwendung Ses- sion-IDs generieren kann, MUSS diese Funktion des Frameworks von den Entwicklern verwendet werden. Sicher- heitsrelevante Konfigurationsmöglichkeiten des Frameworks MÜSSEN berücksichtigt werden. Die Session-ID MUSS ausreichend geschützt werden, wenn sie übertragen und vom Client gespeichert wird. IT-Grundschutz-Kompendium: Stand Februar 2020 3
APP.3: Netzbasierte Dienste APP.3.1 Eine Webanwendung MUSS den Benutzern die Möglichkeit geben, eine bestehende Sitzung explizit zu beenden. Nachdem sich der Benutzer angemeldet hat, MUSS eine bereits bestehende Session-ID durch eine neue ersetzt werden. Sitzungen MÜSSEN eine maximale Gültigkeitsdauer besitzen (Timeout). Inaktive Sitzungen MÜSSEN auto- matisch nach einer bestimmten Zeit ungültig werden. Nachdem die Sitzung ungültig ist, MÜSSEN alle Sitzungsda- ten sowohl server- als auch clientseitig ungültig und gelöscht sein. APP.3.1.A4 Kontrolliertes Einbinden von Daten und Inhalten bei Webanwendungen [Entwickler] (B) Entwickler MÜSSEN sicherstellen, dass eine Webanwendung ausschließlich vorgesehene Daten und Inhalte einbin- det und an den Benutzer ausliefert. Falls eine Webanwendung eine Upload-Funktion für Dateien anbietet, MUSS diese Funktion durch den IT-Betrieb so weit wie möglich eingeschränkt werden. Auch Zugriffs- und Ausführungs- rechte MÜSSEN in diesem Fall restriktiv gesetzt werden. Zudem MUSS sichergestellt werden, dass ein Benutzer Da- teien nur im vorgegebenen Pfad speichern kann. Die Entwickler MÜSSEN sicherstellen, dass der Benutzer den Abla- geort der Uploads nicht beeinflussen kann. Die Ziele der Weiterleitungsfunktion einer Webanwendung MÜSSEN ausreichend eingeschränkt werden, sodass Benutzer ausschließlich auf vertrauenswürdige Webseiten weitergeleitet werden. Verlässt ein Benutzer die Vertrau- ensdomäne, MUSS ihn die Webanwendung darüber informieren. APP.3.1.A5 Protokollierung sicherheitsrelevanter Ereignisse von Webanwendungen [Entwickler] (B) Entwickler MÜSSEN sicherstellen, dass eine Webanwendung sicherheitsrelevante Ereignisse mit den erforderlichen Merkmalen nachvollziehbar protokolliert. Die sicherheitsrelevanten Protokollierungsdaten MÜSSEN regelmäßig durch den IT-Betrieb ausgewertet werden. Bei der Auswertung der Protokollierungsdaten MUSS sichergestellt wer- den, dass Schadcode in Protokoll-Einträgen vom Auswertungsprogramm nicht interpretiert wird. APP.3.1.A6 ENTFALLEN (B) Diese Anforderung ist entfallen. APP.3.1.A7 Schutz vor unerlaubter automatisierter Nutzung von Webanwendungen [Entwickler] (B) Die Entwickler einer Webanwendung und deren Betreiber MÜSSEN sicherstellen, dass die Anwendung vor automa- tisierten Zugriffen geschützt wird. Dabei MUSS jedoch berücksichtigt werden, wie sich die Schutzmechanismen auf die Nutzungsmöglichkeiten berechtigter Benutzer auswirken. Wenn die Webanwendung RSS-Feeds oder andere Funktionen enthält, die explizit für die automatisierte Nutzung vorgesehen sind, MUSS dies ebenfalls bei der Konfi- guration der Schutzmechanismen berücksichtigt werden. APP.3.1.A14 Schutz vertraulicher Daten [Entwickler] (B) Entwickler MÜSSEN sicherstellen, dass die Daten vom Client zum Server nur mit der HTTP-Post-Methode übertra- gen werden. Entwickler MÜSSEN sicherstellen, dass die Webanwendung durch Direktiven gewährleistet, dass clientseitig keine schützenswerten Daten zwischengespeichert werden. Weiterhin MÜSSEN Entwickler sicherstellen, dass in Formula- ren keine vertraulichen Formulardaten im Klartext angezeigt werden. Die Webanwendung SOLLTE verhindern, dass vertrauliche Daten vom Webbrowser unerwartet gespeichert werden. Zugangsdaten der Webanwendung MÜS- SEN serverseitig mithilfe von sicheren kryptografischen Algorithmen vor unbefugtem Zugriff geschützt werden (Sal- ted Hash). Ebenso MÜSSEN die Dateien mit den Quelltexten der Webanwendung vor unerlaubten Abrufen ge- schützt werden. APP.3.1.A16 Umfassende Eingabevalidierung und Ausgabekodierung [Entwickler] (B) Alle an eine Webanwendung übergebenen Daten MÜSSEN von den Entwicklern als potenziell gefährlich behandelt und geeignet gefiltert werden. Alle Eingabedaten sowie Datenströme und Sekundärdaten wie z. B. Session-IDs MÜSSEN validiert werden. Serverseitig SOLLTEN die Daten auf einem vertrauenswürdigen IT-System geprüft werden. Fehleingaben SOLLTEN möglichst nicht automatisch behandelt werden (Sanitizing). Lässt es sich jedoch nicht vermeiden, MUSS Sanitizing sicher umgesetzt werden. Ausgabedaten MÜSSEN so kodiert werden, dass schadhafter Code auf dem Zielsystem nicht interpretiert oder aus- geführt wird. 4 IT-Grundschutz-Kompendium: Stand Februar 2020
APP.3.1 APP.3: Netzbasierte Dienste APP.3.1.A19 Schutz vor SQL-Injection [Entwickler] (B) Werden Daten an ein Datenbank-System weitergeleitet, MÜSSEN die Entwickler Stored Procedures bzw. Prepared SQL Statements einsetzen, wenn dies von der Einsatzumgebung unterstützt wird. Wenn weder Stored Procedures noch Prepared SQL Statements eingesetzt werden können, MÜSSEN die SQL-Queries separat abgesichert werden. 3.2 Standard-Anforderungen Gemeinsam mit den Basis-Anforderungen entsprechen die folgenden Anforderungen dem Stand der Technik für den Baustein APP.3.1 Webanwendungen. Sie SOLLTEN grundsätzlich erfüllt werden. APP.3.1.A8 Systemarchitektur einer Webanwendung [Beschaffer, Entwickler] (S) Bereits in der Entwurfsphase einer Webanwendung SOLLTE der Beschaffer Sicherheitsaspekte beachten. Auch SOLLTE darauf geachtet werden, dass die Architektur der Webanwendung die Geschäftslogik der Institution exakt erfasst und korrekt umsetzt. In der Systemarchitektur SOLLTE der IT-Betrieb vorsehen, dass die Serverdienste durch jeweils separate IT-Systeme voneinander getrennt sind. Auch SOLLTEN jeweils eigene Benutzerkonten für die unterschiedlichen Serverprozesse der Systemkomponenten verwendet werden. Dabei SOLLTEN die Rechte dieser Dienstkonten auf Betriebssystem- ebene soweit eingeschränkt werden, dass nur auf die erforderlichen Ressourcen und Dateien des Betriebssystems zugegriffen werden kann. Die Softwarearchitektur der Webanwendung SOLLTE mit allen Bestandteilen und Abhängigkeiten von den Ent- wicklern dokumentiert werden. Die Dokumentation SOLLTE bereits während des Projektverlaufs aktualisiert und angepasst werden. Die Dokumentation SOLLTE so gestaltet sein, dass Entscheidungen nachvollziehbar sind und sie schon in der Entwicklungsphase benutzt werden kann. Es SOLLTEN in der Dokumentation alle für den Betrieb notwendigen Komponenten, die nicht Bestandteil der Webanwendung sind, als solche gekennzeichnet werden. Ebenso SOLLTE daraus hervorgehen, welche Komponenten welche Sicherheitsmechanismen umsetzen, wie die Webanwendung in eine bestehende Infrastruktur integriert wird und welche kryptografischen Funktionen und Ver- fahren eingesetzt werden. APP.3.1.A9 Beschaffung, Entwicklung und Erweiterung von Webanwendungen [Entwickler, Beschaffer] (S) Wenn Produkte für Webanwendungen beschafft werden, SOLLTE vom Beschaffer ein Anforderungskatalog erstellt werden. Um verschiedene Produkte miteinander vergleichen zu können, SOLLTE eine Bewertungsskala entwickelt werden. Wird die eigentliche Webanwendung oder eine Erweiterung dazu selbst entwickelt, SOLLTEN die Entwickler ein geeignetes Vorgehensmodell benutzen. Dabei SOLLTEN vor der Inbetriebnahme alle Phasen des Modells durchlau- fen werden. Für die Entwicklung SOLLTEN zudem Programmierrichtlinien vorgegeben werden, die dabei helfen, ein einheitliches Sicherheitsniveau zu etablieren. Wenn die Sicherheitsmechanismen einer Webanwendung entworfen und entwickelt werden, SOLLTEN diese mög- lichst künftige Standards und Angriffstechniken berücksichtigen. Bei der Anwendungsentwicklung SOLLTEN die Entwicklungs-, Test- und Produktivsysteme voneinander getrennt sein. Falls die Webanwendung von einem Dienstleister entwickelt wird, SOLLTE der Beschaffer sicherstellen, dass der Dienstleister die nötigen Sicherheitsanforderungen bei der Entwicklung umsetzt und der Auftraggeber jederzeit auf den Quelltext zugreifen kann. APP.3.1.A10 ENTFALLEN (S) Diese Anforderung ist entfallen. APP.3.1.A11 Sichere Anbindung von Hintergrundsystemen (S) Hintergrundsysteme von Webanwendungen, auf denen Funktionalitäten und Daten ausgelagert werden, SOLLTEN ausreichend geschützt werden. Der Zugriff auf Hintergrundsysteme SOLLTE ausschließlich über definierte Schnitt- stellen und von definierten Systemen aus möglich sein. Bei der Kommunikation über Standort- und Netzgrenzen hinweg SOLLTE der Datenverkehr authentisiert und verschlüsselt werden. Zugriffe der Webanwendung auf Hinter- grundsysteme SOLLTEN zudem mit minimalen Rechten erfolgen. IT-Grundschutz-Kompendium: Stand Februar 2020 5
APP.3: Netzbasierte Dienste APP.3.1 Beim Einsatz eines Enterprise Service Bus (ESB) SOLLTE ein eigenes logisches Netzsegment für den ESB vorhanden sein. Der Zugriff auf den ESB SOLLTE ausschließlich durch die angeschlossenen Anwendungen und Dienste möglich sein. Alle Zugriffe auf den ESB SOLLTEN authentisiert und bei der Kommunikation über Standort- und Netzgrenzen hinweg verschlüsselt sein. APP.3.1.A12 Sichere Konfiguration von Webanwendungen (S) Eine Webanwendung SOLLTE so konfiguriert sein, dass auf ihre Ressourcen und Funktionen ausschließlich über die vorgesehenen, abgesicherten Kommunikationspfade zugegriffen werden kann. Der Zugriff auf nicht benötigte Ressourcen und Funktionen SOLLTE daher eingeschränkt werden. Folgendes SOLLTE bei der Konfiguration von Webanwendungen berücksichtigt werden: • Deaktivierung nicht benötigter HTTP-Methoden, • Zeichenkodierungskonfiguration, • Festlegung von Grenzwerten für Zugriffsversuche sowie • Administration einer Webanwendung. APP.3.1.A13 Restriktive Herausgabe sicherheitsrelevanter Informationen (S) Webseiten und Rückantworten von Webanwendungen SOLLTEN keine Informationen enthalten, die einem Angrei- fer Hinweise darauf geben, wie er Sicherheitsmechanismen umgehen kann. Konfigurationsdateien der Webanwendung SOLLTEN außerhalb des Web-Root-Verzeichnisses gespeichert wer- den. APP.3.1.A15 Verifikation essenzieller Änderungen [Entwickler] (S) Sollen wichtige Einträge geändert werden, SOLLTEN die Entwickler sicherstellen, dass die Änderungen durch die Eingabe eines Passworts erneut verifiziert werden. Falls dies nicht möglich ist, SOLLTE die Anwendung auf andere geeignete Weise sicherstellen, dass sich der Benutzer authentisiert. Die Benutzer SOLLTEN über Änderungen mit- hilfe von Kommunikationswegen außerhalb der Web-Anwendung informiert werden. APP.3.1.A17 Fehlerbehandlung [Entwickler] (S) Treten während des Betriebs einer Webanwendung Fehler auf, SOLLTEN Entwickler diese so behandeln, dass die Webanwendung weiter in einem konsistenten Zustand bleibt. Das heißt: • Fehlermeldungen SOLLTEN protokolliert werden, • eine veranlasste Aktion SOLLTE im Fehlerfall abgebrochen werden und • in der Folge SOLLTE der Zugriff auf die angeforderte Ressource oder Funktion abgewiesen werden. Zuvor reservierte Ressourcen SOLLTEN im Rahmen der Fehlerbehandlung wieder freigegeben werden. Auch SOLLTE der Fehler möglichst von der Webanwendung selbst behandelt werden. APP.3.1.A18 ENTFALLEN (S) Diese Anforderung ist entfallen. APP.3.1.A21 Sichere HTTP-Konfiguration bei Webanwendungen [Entwickler] (S) Zum Schutz vor Clickjacking, Cross-Site-Scripting und anderen Angriffen SOLLTEN die Entwickler sowie der IT-Be- trieb geeignete HTTP-Response-Header setzen. Dazu SOLLTEN mindestens die folgenden Direktiven verwendet werden: Content-Security-Policy, möglicherweise X-FRAME-OPTIONS, Strict-Transport-Security, X-XSS-Protection, Content-Type, X-Content-Type-Options sowie Cache-Control. Cookies SOLLTEN grundsätzlich mit den Attributen secure und httponly gesetzt werden. APP.3.1.A22 Überprüfung von Webanwendungen (S) Webanwendungen SOLLTEN regelmäßig auf Sicherheitsprobleme hin überprüft werden. Auch SOLLTEN regelmä- ßig Revisionen durchgeführt werden. Die Ergebnisse SOLLTEN nachvollziehbar dokumentiert, ausreichend ge- 6 IT-Grundschutz-Kompendium: Stand Februar 2020
APP.3.1 APP.3: Netzbasierte Dienste schützt und vertraulich behandelt werden. Abweichungen SOLLTE nachgegangen werden. Die Ergebnisse SOLLTEN dem ISB vorgelegt werden. APP.3.1.A23 Verhinderung von Cross-Site-Request-Forgery [Entwickler] (S) Die Entwickler einer Webanwendung SOLLTEN diese mit Sicherheitsmechanismen ausstatten, die es ermöglichen, beabsichtigte Seitenaufrufe des Benutzers von unbeabsichtigt weitergeleiteten Befehlen Dritter zu unterscheiden. Mindestens SOLLTE dabei geprüft werden, ob neben der Session-ID ein geheimes Token für den Zugriff auf ge- schützte Ressourcen und Funktionen benötigt wird. 3.3 Anforderungen bei erhöhtem Schutzbedarf Im Folgenden sind für den Baustein APP.3.1 Webanwendungen exemplarische Vorschläge für Anforderungen auf- geführt, die über das dem Stand der Technik entsprechende Schutzniveau hinausgehen und BEI ERHÖHTEM SCHUTZBEDARF in Betracht gezogen werden SOLLTEN. Die konkrete Festlegung erfolgt im Rahmen einer Risiko- analyse. APP.3.1.A20 Einsatz von Web Application Firewalls (H) Institutionen SOLLTEN auf Web Application Firewalls (WAF) zurückgreifen. Wird eine WAF eingesetzt, SOLLTE die Konfiguration auf die zu schützende Webanwendung angepasst werden. Die Konfiguration der WAF SOLLTE nach jedem Update der Webanwendung geprüft werden. APP.3.1.A24 Verhinderung der Blockade von Ressourcen [Entwickler] (H) Zum Schutz vor Denial-of-Service (DoS)-Angriffen SOLLTEN ressourcenintensive Operationen vermieden und be- sonders abgesichert werden. Ebenso SOLLTE ein möglicher Überlauf von Protokollierungsdaten bei Webanwen- dungen überwacht und verhindert werden. APP.3.1.A25 Kryptografische Sicherung vertraulicher Daten [Entwickler] (H) Entwickler und Betreiber einer Webanwendung SOLLTEN sicherstellen, dass vertrauliche Daten einer Webanwen- dung durch sichere, kryptografische Algorithmen geschützt werden. 4 Weiterführende Informationen 4.1 Wissenswertes Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt im Dokument „Hilfsmittel zur Nutzung des Bau- steins Webanwendungen“ Hinweise zum Umgang mit diesem Baustein zur Verfügung. Das Open Web Application Security Projekt stellt auf seiner Webseite Hinweise zur Absicherung von Webanwen- dungen zur Verfügung. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellt im Dokument „Kryptographische Verfahren: Empfehlungen und Schlüssellängen: BSI TR-02102“ Hinweise zur Anwendung kryptografischer Verfahren zur Ver- fügung. 5 Anlage: Kreuzreferenztabelle zu elementaren Gefährdungen Die Kreuzreferenztabelle enthält die Zuordnung von elementaren Gefährdungen zu den Anforderungen. Anhand dieser Tabelle lässt sich ermitteln, welche elementaren Gefährdungen durch welche Anforderungen abgedeckt sind. Durch die Umsetzung der aus den Anforderungen abgeleiteten Sicherheitsmaßnahmen wird den entspre- chenden elementaren Gefährdungen entgegengewirkt. Die Buchstaben in der zweiten Spalte (C = Vertraulichkeit, I = Integrität, A = Verfügbarkeit) zeigen an, welche Grundwerte der Informationssicherheit durch die Anforderung vorrangig geschützt werden. Die folgenden elementaren Gefährdungen sind für den Baustein APP.3.1 Webanwendungen von Bedeutung. G 0.18 Fehlplanung oder fehlende Anpassung G 0.19 Offenlegung schützenswerter Informationen IT-Grundschutz-Kompendium: Stand Februar 2020 7
APP.3: Netzbasierte Dienste APP.3.1 G 0.20 Informationen oder Produkte aus unzuverlässiger Quelle G 0.21 Manipulation von Hard- oder Software G 0.22 Manipulation von Informationen G 0.23 Unbefugtes Eindringen in IT-Systeme G 0.28 Software-Schwachstellen oder -Fehler G 0.30 Unberechtigte Nutzung oder Administration von Geräten und Systemen G 0.32 Missbrauch von Berechtigungen G 0.36 Identitätsdiebstahl G 0.39 Schadprogramme G 0.40 Verhinderung von Diensten (Denial of Service) G 0.43 Einspielen von Nachrichten G 0.46 Integritätsverlust schützenswerter Informationen Elementare CIA- G 0.18 G 0.19 G 0.20 G 0.21 G 0.22 G 0.23 G 0.28 G 0.30 G 0.32 G 0.36 G 0.39 G 0.40 G 0.43 G 0.46 Gefährdungen Werte Anforderungen APP.3.1.A1 X X X X X X X APP.3.1.A2 X X X X X X X APP.3.1.A3 X X X X X X X X APP.3.1.A4 X X X X X X X X X APP.3.1.A5 X X X X APP.3.1.A6 APP.3.1.A7 X X X APP.3.1.A8 X X X X APP.3.1.A9 X X X X X X X X APP.3.1.A10 APP.3.1.A11 X X X X X X X X X X X X X APP.3.1.A12 X X X X X X X X APP.3.1.A13 X X X X X X APP.3.1.A14 X X X X X APP.3.1.A15 X X X APP.3.1.A16 X X X X APP.3.1.A17 X X X X X X X X X APP.3.1.A18 APP.3.1.A19 X X X X X X X X X APP.3.1.A20 CIA X X X X X X X X X X X APP.3.1.A21 X X X X APP.3.1.A22 X X X X X X X X X X X X APP.3.1.A23 X X X X X X X X APP.3.1.A24 A X APP.3.1.A25 CI X X 8 IT-Grundschutz-Kompendium: Stand Februar 2020
APP.3.2 APP.3: Netzbasierte Dienste APP.3.2: Webserver 1 Beschreibung 1.1 Einleitung Ein Webserver ist die Kernkomponente jedes Webangebotes: Er nimmt Anfragen der Clients über einen Browser entgegen und liefert die entsprechenden Inhalte zurück. Der Transport der Daten erfolgt in der Regel über das Hypertext Transfer Protocol (HTTP) oder dessen mit Transport Layer Security (TLS) verschlüsselte Variante HTTP Secure (HTTPS). Da Webserver eine einfache Schnittstelle zwischen Serveranwendungen und Benutzern bieten, werden sie auch häufig für interne Informationen und Anwendungen in Institutionsnetzen, wie dem Intranet, ein- gesetzt. Webserver sind in der Regel direkt im Internet verfügbar und bieten somit eine exponierte Angriffsfläche. Deswe- gen müssen sie durch geeignete Schutzmaßnahmen abgesichert werden. 1.2 Zielsetzung Ziel dieses Bausteins ist der Schutz des Webservers und der Informationen, die durch den Webserver bereitgestellt oder damit verarbeitet werden. 1.3 Abgrenzung und Modellierung Der Baustein muss auf alle Webserver des Informationsverbunds angewendet werden. Die Bezeichnung Webserver wird sowohl für die Software verwendet, welche die HTTP-Anfragen beantwortet, als auch für die IT-Systeme, auf denen diese Software ausgeführt wird. In diesem Baustein wird vorrangig die Webser- ver-Software betrachtet. Sicherheitsaspekte des IT-Systems, auf dem die Webserver-Software installiert ist, werden in den entsprechenden Bausteinen der Schicht SYS IT-Systeme behandelt (siehe SYS.1.1 Allgemeiner Server sowie beispielsweise SYS.1.3 Server unter Linux und Unix oder SYS.1.2.2 Windows Server 2012). Empfehlungen, wie Webserver in die Netzarchitektur zu integrieren und mit Firewalls abzusichern sind, finden sich in den Bausteinen NET.1.1 Netzarchitektur und -design bzw. NET.3.2 Firewall. Der Baustein behandelt grundsätzliche Aspekte, die für die Bereitstellung von Webinhalten wichtig sind. Dynami- sche Inhalte, die durch Webanwendungen bereitgestellt werden, sind nicht Gegenstand des vorliegenden Bau- steins. Diese werden im Baustein APP.3.1 Webanwendungen behandelt. Ebenso werden hier keine Webservices betrachtet. In der Regel werden die Verbindungen zu Webservern verschlüsselt. Der Baustein CON.1 Kryptokonzept be- schreibt, wie die dazu notwendigen kryptografischen Schlüssel sicher verwaltet werden können. Werden Webserver nicht selbst betrieben, sondern über einen Hosting-Anbieter bereitgestellt, ist der Baustein OPS.2.1 Outsourcing für Kunden zu beachten. IT-Grundschutz-Kompendium: Stand Februar 2020 1
APP.3: Netzbasierte Dienste APP.3.2 2 Gefährdungslage Folgende spezifische Bedrohungen und Schwachstellen sind für den Baustein APP.3.2 Webserver von besonderer Bedeutung: 2.1 Reputationsverlust Schaffen es Angreifer, mit administrativen Rechten auf einen Webserver zuzugreifen, können sie darüber eine ma- nipulierte Webseite ausliefern (Defacement). So kann die Reputation der Institution geschädigt werden. Ebenso kann die Veröffentlichung falscher Informationen, wie zum Beispiel fehlerhafter Produktbeschreibungen, dazu füh- ren, dass die Reputation der Institution in der Öffentlichkeit leidet. Auch kann die Institution abgemahnt werden, wenn auf ihrer Webseite Inhalte veröffentlicht werden, die gegen gesetzliche Vorschriften verstoßen. Ein Schaden kann auch entstehen, wenn die Webseite nicht verfügbar ist und potenzielle Kunden deshalb zu Mitbewerbern wechseln. 2.2 Manipulation des Webservers Ein Angreifer kann sich Zugriff auf einen Webserver verschaffen und dessen Dateien manipulieren. Er könnte bei- spielsweise die Konfiguration der Webserver-Software ändern, Schadsoftware verbreiten oder Webinhalte modifi- zieren. 2.3 Denial of Service (DoS) Durch DoS-Angriffe lässt sich die Verfügbarkeit eines Webangebotes gezielt beeinträchtigen, indem beispielsweise einzelne Accounts durch fehlerhafte Anmeldungen gesperrt werden. Ein Angreifer könnte z. B. durch ungültige Anmeldeversuche erreichen, dass Benutzerkonten gesperrt werden. Durch DDoS (Distributed Denial of Service)-Angriffe kann ein Webserver teilweise oder auch ganz ausfallen. Für Benutzer ist das Webangebot dann nur noch sehr langsam oder gar nicht mehr verfügbar. Für viele Institutionen kann ein solcher Ausfall schnell geschäftskritisch werden, z. B. für Online-Shops. 2.4 Verlust vertraulicher Daten Viele Webserver verwenden noch veraltete kryptografische Verfahren wie RC4 oder SSL. Eine unzureichende Au- thentisierung bzw. eine ungeeignete Verschlüsselung kann dazu führen, dass Angreifer die Kommunikation zwi- schen den Clients und den Webservern mitlesen oder ändern können. Das gleiche gilt für die Kommunikation zwi- schen dem Webserver und anderen Servern, wie z. B. Load Balancern. 2.5 Verstoß gegen Gesetze oder Regelungen Für die Veröffentlichung von Webinhalten gibt es verschiedene regulatorische Anforderungen. Neben den Rege- lungen der Telemedien- und Datenschutzgesetze, sind auch die Regeln des Urheberrechts zu beachten. Verstöße gegen diese Gesetze können rechtliche Konsequenzen nach sich ziehen. 2.6 Software-Schwachstellen oder -Fehler Solange Updates und Patches für kritische Sicherheitslücken des Webservers oder benutzte Erweiterungen nicht eingespielt wurden, kann der Webserver erfolgreich angegriffen werden. Dadurch können Angreifer Dateien oder Dienste manipulieren oder den Webserver für weitere Angriffe missbrauchen. 2.7 Fehlende oder mangelhafte Fehlerbehebung Treten während des Betriebs eines Webservers Fehler auf, kann sich das z. B. auf dessen Verfügbarkeit auswirken. Auch werden eventuell Inhalte unvollständig dargestellt oder Sicherheitsmechanismen fallen aus. Werden Fehler nicht korrekt behandelt, sind sowohl der Betrieb als auch der Schutz der Funktionen und Daten eines Webservers nicht mehr gewährleistet. 2 IT-Grundschutz-Kompendium: Stand Februar 2020
APP.3.2 APP.3: Netzbasierte Dienste 2.8 Unzureichende Protokollierung von sicherheitsrelevanten Ereignissen Werden sicherheitsrelevante Ereignisse vom Webserver unzureichend protokolliert, können diese zu einem späte- ren Zeitpunkt nicht nachvollzogen werden. Die Ursache kann dann nicht mehr ermittelt werden. Kritische Fehler und Angriffe, wie beispielsweise unbefugte Konfigurationsänderungen, bleiben so lange Zeit unbemerkt. 3 Anforderungen Im Folgenden sind die spezifischen Anforderungen des Bausteins APP.3.2 Webserver aufgeführt. Grundsätzlich ist der IT-Betrieb für die Erfüllung der Anforderungen zuständig. Der Informationssicherheitsbeauftragte (ISB) ist bei strategischen Entscheidungen stets einzubeziehen. Außerdem ist der ISB dafür zuständig, dass alle Anforderungen gemäß dem festlegten Sicherheitskonzept erfüllt und überprüft werden. Zusätzlich kann es noch andere Rollen geben, die weitere Zuständigkeiten bei der Umsetzung von Anforderungen haben. Diese sind dann jeweils explizit in eckigen Klammern in der Überschrift der jeweiligen Anforderungen aufgeführt. Grundsätzlich zuständig IT-Betrieb Weitere Zuständigkeiten Fachverantwortliche, Leiter IT 3.1 Basis-Anforderungen Die folgenden Anforderungen MÜSSEN für den Baustein APP.3.2 Webserver vorrangig erfüllt werden: APP.3.2.A1 Sichere Konfiguration eines Webservers (B) Nachdem der IT-Betrieb einen Webserver installiert hat, MUSS er eine sichere Grundkonfiguration vornehmen. Dazu MUSS er insbesondere den Webserver-Prozess einem Benutzerkonto mit minimalen Rechten zuweisen. Der Webserver MUSS in einer gekapselten Umgebung ausgeführt werden, sofern dies vom Betriebssystem unterstützt wird. Dem Webserver-Dienst MÜSSEN alle nicht notwendige Schreibberechtigungen entzogen werden. Nicht be- nötigte Module und Funktionen des Webservers MÜSSEN deaktiviert werden. APP.3.2.A2 Schutz der Webserver-Dateien (B) Der IT-Betrieb MUSS alle Dateien auf dem Webserver, insbesondere Skripte und Konfigurationsdateien, so schüt- zen, dass sie nicht unbefugt gelesen und geändert werden können. Es MUSS sichergestellt werden, dass Webanwendungen nur auf einen definierten Verzeichnisbaum zugreifen kön- nen (WWW-Wurzelverzeichnis). Der Webserver MUSS so konfiguriert sein, dass er nur Dateien ausliefert, die sich innerhalb des WWW-Wurzelverzeichnisses befinden. Der IT-Betrieb MUSS alle nicht benötigten Funktionen, die Verzeichnisse auflisten, deaktivieren. Er MUSS Dateien, die nicht verändert werden sollen, vor Schreibzugriffen schützen. Vertrauliche Daten MÜSSEN vor unberechtigtem Zugriff geschützt werden. Insbesondere MUSS der IT-Betrieb sicherstellen, dass vertrauliche Dateien nicht in öffent- lichen Verzeichnissen des Webservers liegen. APP.3.2.A3 Absicherung von Datei-Uploads und -Downloads (B) Alle mithilfe des Webservers veröffentlichten Dateien MÜSSEN vorher auf Schadprogramme geprüft werden. Es MUSS eine Maximalgröße für Datei-Uploads spezifiziert sein. Für Uploads MUSS genügend Speicherplatz reser- viert werden. APP.3.2.A4 Protokollierung von Ereignissen (B) Der Webserver MUSS mindestens folgende Ereignisse protokollieren: • erfolgreiche Zugriffe auf Ressourcen, • fehlgeschlagene Zugriffe auf Ressourcen aufgrund von mangelnder Berechtigung, nicht vorhandenen Ressour- cen und Server-Fehlern sowie • allgemeine Fehlermeldungen. Die Protokollierungsdaten SOLLTEN regelmäßig ausgewertet werden. IT-Grundschutz-Kompendium: Stand Februar 2020 3
