Bundesamt für Sicherheit in der Informationstechnik

M 4.398 Sichere Konfiguration von Webanwendungen

Verantwortlich für Initiierung: Leiter IT

Verantwortlich für Umsetzung: Entwickler, Administrator

Ist eine Webanwendung unzureichend konfiguriert, so kann ein Angreifer möglicherweise bestehende Sicherheitsmechanismen überwinden. Daher muss sichergestellt werden, dass die Webanwendung so konfiguriert wird, dass Zugriffe ausschließlich über die vorgesehenen, abgesicherten Kommunikationspfade möglich sind. Der Zugriff auf nicht benötigte Ressourcen und Funktionen ist daher einzuschränken.

Folgende Punkte sollten bei der Konfiguration der Webanwendung berücksichtigt werden:

Deaktivierung nicht benötigter HTTP-Methoden

Auf eine Webanwendung kann gemäß HTTP -Standard mit unterschiedlichen HTTP-Methoden ( z. B. GET, POST, PUT, DELETE oder TRACE) zugegriffen werden. Üblicherweise benötigt eine Webanwendung jedoch nur eine sehr eingeschränkte Menge dieser HTTP-Methoden (z. B. GET und POST).

Darüber hinaus kann eine Webanwendung in Abhängigkeit der verwendeten HTTP-Methode unterschiedlich auf einen Request reagieren. Wird beispielsweise die Eingabedatenfilterung nur bei einem GET- oder POST-Request durchgeführt, so kann diese Sicherheitsfunktion durch den Aufruf einer nicht vorgesehenen HTTP-Methode gegebenenfalls umgangen werden.

Einige HTTP-Methoden (z. B. PUT) bieten Zugriff auf sicherheitskritische Funktionalität (z. B. Hochladen beliebiger Dateien) und ermöglichen auf diese Weise Restriktionen der Webanwendung zu umgehen (z. B. die Dateitypenprüfung bei einer Upload-Funktion).

Aus diesen Gründen sollten nicht benötigte HTTP-Methoden deaktiviert und von der Webanwendung nicht bearbeitet werden. Dies gilt auch für fiktive HTTP-Methoden, die nicht im entsprechenden Standard RFC 2616 definiert werden. Auch wenn die HTTP-Methoden bereits in der Konfiguration des Webservers deaktiviert wurden, sollte auch die Webanwendung nicht benötigte HTTP-Requests nicht bearbeiten.

Erzwingen der HTTP-POST-Methode

Bei der Bedienung einer Webanwendung werden üblicherweise Daten (z. B. Formulardaten oder die Session ID ) an die Webanwendung übermittelt. Diese Daten können als Parameter in der URL (GET-Methode) und im Rumpf des HTTP-Requests (POST-Methode) übertragen werden.

Bei der Verwendung der GET-Methode sind vertrauliche Daten wie Formulardaten in der URL sichtbar (z. B. im Browser-Verlauf) und können von zwischengelagerten Systemen protokolliert und gespeichert werden.

Daher sollten schützenswerte Daten ausschließlich über die POST-Methode übertragen werden. Hierbei ist zu berücksichtigen, dass Frameworks häufig die HTTP-Request-Methode abstrahieren. Eine falsche Konfiguration des Frameworks kann dazu führen, dass trotz erzwungener Eingrenzung auf die POST-Methode durch die Webanwendung weiterhin beide Methoden zulässig sind (z. B. über eine Weiterleitung eines HTTP-GET-Requests auf einen HTTP-POST-Request durch das Framework).

Sicherer Umgang mit SSL/TLS

Zum Schutz der übertragenen Daten zwischen Webanwendung und Client des Benutzers kann der Transportkanal durch kryptographische Verfahren (z. B. SSL / TLS ) geschützt werden. Vertrauliche Daten sollten immer über einen verschlüsselten Transportkanal übertragen werden (siehe auch M 5.66 Clientseitige Verwendung von SSL/TLS ).

Darüber hinaus ist darauf zu achten, dass bei Fehlern während des SSL/TLS-Verbindungsaufbaus oder bei der Übertragung von Daten über einen verschlüsselten Kanal nicht zu einer unverschlüsselten Verbindung gewechselt wird. Stattdessen sollte der Verbindungsaufbau erneut erfolgen oder abgelehnt werden. Es muss verhindert werden, dass vertrauliche Daten über eine ungesicherte Verbindung übertragen werden (z. B. durch setzen des Secure-Flags für Cookies; siehe M 4.401 Schutz vertraulicher Daten bei Webanwendungen ).

Zeichenkodierungskonfiguration

Die übermittelten Daten zwischen dem Client des Benutzers und der Webanwendung können in verschiedenen Kodierungen vorliegen. Abhängig von der erwarteten Kodierung werden die Daten von Clients, von der Webanwendung oder von den Hintergrundsystemen unterschiedlich interpretiert. Damit Clients Daten an die Webanwendung in der gewünschten Kodierung senden, sollte die Webanwendung bei der Auslieferung von Webseiten in den Header-Feldern der HTTP-Response das Zeichenkodierungsschema (z. B. UTF-8) mit angeben.

Falls die Webanwendung international verwendet wird, sollte darauf geachtet werden, dass alle internationalen Zeichensätze auf allen logischen Ebenen der Webanwendung und von den angebundenen Hintergrundsystemen unterstützt werden.

Speicherung von Konfigurationsdateien außerhalb von Web-Root

Konfigurationsdateien der Webanwendung enthalten häufig schützenswerte Informationen wie z. B. Zugangsdaten. Daher dürfen Benutzer der Webanwendung keine Zugriffsmöglichkeiten auf die Konfigurationsdateien haben.

Aus diesem Grund sollten Konfigurationsdateien ausschließlich außerhalb des Webserver-Root-Verzeichnisses gespeichert werden. Außerhalb dieses Verzeichnisses werden in der Regel keine Daten von der Webanwendung ausgeliefert.

Grundsätzlich müssen Konfigurationsdaten außerhalb des Quelltextes in separaten Konfigurationsdateien gespeichert werden. Konfigurationseinstellungen, die vertrauliche Daten beinhalten, sollten zudem verschlüsselt werden.

Festlegung von Grenzwerten

Einige Schutzmechanismen sehen den Einsatz von Grenzwerten vor (siehe z. B. M 4.396 Schutz vor unerlaubter automatisierter Nutzung von Webanwendungen . Wird ein Grenzwert überschritten, erfolgt häufig die zeitweise Sperrung einer betroffenen Funktion oder Ressource. So können wiederholt fehlgeschlagene Anmeldeversuche die Sperrung des Benutzer-Kontos zur Folge haben (z. B. zur Abwehr von Brute-Force-Angriffen).

Auf diese Weise eingeleitete Maßnahmen können die Bedienung der Webanwendung beeinflussen und somit ebenfalls unbeteiligte Benutzer betreffen. Diese Benutzer können sich beispielsweise nicht mehr an der Webanwendung anmelden, falls ihr Benutzer-Konto gesperrt wurde.

Diese Auswirkungen sollten daher auch bei der Festlegung von Grenzwerten berücksichtigt werden.

Restriktive Dateisystemberechtigungen

Webanwendungen bieten Benutzern häufig direkt oder indirekt Zugriff auf das darunterliegende Dateisystem (z. B. über abrufbare Dateien oder eine Upload-Funktion). Damit ein Angreifer nicht unbefugt schützenswerte Dateien lesen oder manipulieren kann, sollten diese zusätzlich zu Zugriffsbeschränkungen auf Webanwendungsebene durch restriktive Dateisystemberechtigungen geschützt werden. Der Server, auf dem die Webanwendung läuft, muss mit eingeschränkten Rechten gestartet werden und nicht als Administrator (root).

Administration einer Webanwendung

Die Webanwendung sollte vorrangig über ein von der Anwendung entkoppeltes System administriert werden. Im Fall einer E-Commerce-Anwendung kann beispielsweise die Artikelpflege über ein getrenntes System mit Zugriff auf die Datenbank der Webanwendung erfolgen. Das System sollte idealerweise alleine für diesen Zweck bestimmt sein und keine direkte Verbindung zu der Webanwendung haben. Dementsprechend sollte die Webanwendung die Artikeldaten ausschließlich von der Datenbank abrufen.

Häufig bieten Webanwendungen zur Administration eine Web-Oberfläche auf demselben Server an. Diese Funktion sollte gemieden und stattdessen die Administration über ein separates System durchgeführt werden. Falls die Administration auf demselben Server erforderlich ist, sollte die Administrationsoberfläche ausschließlich aus dem Administrationsnetz heraus erreichbar und der Zugriff durch gewöhnliche Benutzer der Webanwendung nicht möglich sein. Möglichkeiten zur Administration der Webanwendung, die nicht genutzt werden (z. B. Konsole), sollten nicht nutzbar sein.

Prüffragen:

  • Werden bei der Webanwendung ausschließlich die HTTP-Methoden zugelassen, die erforderlich sind?

  • Wird zur Übertragung vertraulicher Daten (z. B. Formulardaten) vorzugsweise die HTTP-POST-Methode verwendet?

  • Werden vertrauliche Daten ausschließlich über einen verschlüsselten Transportkanal übertragen?

  • Wird verhindert, dass im Fall von Verbindungsfehlern bei einem verschlüsselten Kanal nicht auf eine unverschlüsselte Verbindung gewechselt wird?

  • Werden Konfigurationsdateien der Webanwendung außerhalb des Web-Root-Verzeichnisses gespeichert?

  • Wird für die Administration der Webanwendung ein separates System verwendet oder ist die Administrationsoberfläche der Webanwendung nur aus dem Administrationsnetzwerk heraus erreichbar?

Stand: 13. EL Stand 2013

Hinweis zur Verwendung von Cookies

Um unsere Webseite für Sie optimal zu gestalten und fortlaufend verbessern zu können, verwenden wir Cookies. Durch die weitere Nutzung der Webseite stimmen Sie der Verwendung von Cookies zu. Weitere Informationen hierzu erhalten Sie in unserer Datenschutzerklärung.

OK