M 4.393 Umfassende Ein- und Ausgabevalidierung bei Webanwendungen

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

Verantwortlich für Umsetzung: Entwickler, Administrator

Alle an die Webanwendung übergebenen Daten, unabhängig von Kodierung oder Form der Übermittlung, müssen als potenziell gefährlich behandelt und entsprechend gefiltert werden. Durch eine zuverlässige und gründliche Filterung der Ein- und Ausgabedaten mittels einer Validierungskomponente kann ein wirksamer Schutz vor gängigen Angriffen erreicht werden. Hierbei sollten sowohl die Eingabedaten von Benutzern an die Webanwendung als auch die Ausgabedaten der Webanwendung an die Clients gefiltert und transformiert (output encoding) werden. Dadurch wird sichergestellt, dass nur erwartete und keine schadhaften Daten von der Webanwendung verarbeitet oder ausgegeben werden.

Ist es für einzelne Funktionen notwendig, den Datenfilter weniger restriktiv zu setzen, muss dies explizit beim Zugriff auf die Daten definiert und dokumentiert werden. Zusätzlich ist es möglich, kontextsensitive Filter in der Geschäftslogik der Anwendung oder in den Hintergrundsystemen zu nutzen.

Für eine sichere Verarbeitung der Daten sollten folgende Punkte bei Umsetzung und Konfiguration der Validierungskomponente berücksichtigt werden.

Identifizierung der Daten

Damit die Ein- und Ausgabedaten einer Webanwendung umfassend validiert werden können, müssen zunächst alle zu verarbeitenden Datenstrukturen ( z. B. E-Mail-Adresse) und die darin zulässigen Werte identifiziert werden. Für jede Datenstruktur sollte eine entsprechende Validierungsroutine umgesetzt werden. Neben der Datenstruktur sollte auch die Art und Weise der Datenverarbeitung erfasst werden (z. B. Weiterleitung an einen Interpreter, Rückgabe an den Client, Speicherung in einer Datenbank).

Berücksichtigung aller Daten und Datenformate

Die Validierungskomponente sollte alle zu verarbeitenden Datenformate und verwendeten Interpreter berücksichtigen. Typische Datenformate bei Webanwendungen sind z. B. personenbezogene Daten (Name, Telefonnummer, Postleitzahl), Bilder, PDF-Dateien und formatierte Texte. Typische Interpreter für Daten, die von Webanwendungen verarbeitet oder ausgegeben werden, sind z. B. HTML -Renderer, SQL -, XML -, LDAP -Interpreter und das Betriebssystem.

Daten können durch unterschiedliche Techniken auf ihre Gültigkeit geprüft werden. So kann die Validierungskomponente den Wertebereich der Eingaben überprüfen oder es können beispielsweise reguläre Ausdrücke verwendet werden, um erlaubte Zeichen und die Länge der erwarteten Daten zu validieren. Die Gültigkeit von XML-Daten kann unter anderem mithilfe des entsprechenden XML-Schemas überprüft werden. Darüber hinaus stellen Frameworks und Bibliotheken für gängige Datenformate entsprechende Validierungsfunktionen bereit.

Die folgenden Zeichen werden gewöhnlich von in Webanwendungen eingesetzten Programmen interpretiert und können daher für das Einschleusen von schadhaftem Code genutzt werden. Aus diesem Grund sollten sie bei der Filterung berücksichtigt werden:

Nullwert, Zeilenvorschub, Wagenrücklauf, Hochkommata, Kommas, Schrägstriche, Leerzeichen, Tabulator-Zeichen, größer als und kleiner als, XML und HTML-Tags.

Diese Aufzählung erhebt keinen Anspruch auf Vollständigkeit. Zudem können die Interpreter-Zeichensätze (z. B. SQL-Syntax) bei unterschiedlichen Produkten variieren. Beispiele für kritische Zeichen werden im Abschnitt Potentiell gefährliche Zeichen für Interpreter in Hilfsmittel zum Baustein Webanwendung aufgeführt.

Neben den eigentlichen Nutzdaten (z. B. Formular-Parameter in GET- oder POST-Variablen) sind auch Daten anderer Herkunft (Sekundärdaten) zu validieren. Dazu zählen beispielsweise:

Automatisierte Aufrufe durch den Client z. B. durch Ajax- bzw. Flash-Skripte oder JSON-Requests sind ebenfalls zu prüfen.

Bei den Hintergrundsystemen ist eine (gegebenenfalls erneute) Validierung der Daten vorzunehmen. Dies gilt auch dann, wenn Daten beispielsweise nach einem erfolgten Schreibvorgang in die Datenbank wieder ausgelesen werden, da die Daten auch in der Datenbank zwischenzeitlich geändert worden sein können.

Darüber hinaus sind Angriffstechniken bekannt, bei denen schadhafter Code über einen Kanal übermittelt wird, der nicht von der Webanwendung kontrolliert werden kann (z. B. FTP , NFS ). Kann ein Angreifer über diese Dienste Dateien ändern oder erzeugen, die von der Webanwendung integriert werden, so kann Schadcode über diesen Umweg eingebettet werden. Bei dem sogenannten Cross-Channel-Scripting wird auf diese Weise JavaScript-Code eingefügt, der ähnlich wie bei persistentem Cross-Site-Scripting vom Browser ausgeführt wird. Daher sollten unabhängig von der Quelle immer alle Daten der Webanwendung vor der Ausgabe an die Benutzer validiert werden.

Serverseitige Validierung

Üblicherweise greifen die Benutzer mit generischen Clients (z. B. Web-Browser) auf die Webanwendung zu. Diese Clients befinden sich nicht im Sicherheitskontext der Webanwendung, sondern stehen unter der Kontrolle der Benutzer. Die Datenvalidierung ist daher als serverseitiger Sicherheitsmechanismus auf einem vertrauenswürdigen IT-System umzusetzen.

Werden Daten zusätzlich durch Code von der Webanwendung clientseitig verarbeitet (z. B. JavaScript-Code), so sollten diese Daten auch auf dem Client validiert werden. Die ausgelieferten Skripte der Webanwendung sollten hierbei die entsprechenden Validierungsroutinen mitliefern. Werden die Daten im nachgelagerten Verarbeitungsprozess an den Server gesendet, so ist zu beachten, dass die clientseitige Prüfung die serverseitige Validierung nicht ersetzen kann.

Validierungsansatz

Bei der Datenvalidierung wird zwischen dem White-List- und dem Black-List-Ansatz unterschieden.

Bei dem White-List-Ansatz werden ausschließlich solche Daten zugelassen, die in der Liste enthalten sind. Dabei werden, ausgehend von einer möglichst kleinen Zeichenmenge, Regeln erstellt, die Daten in einem festgelegten Zeichenraum zulassen und Daten zurückweisen, die abweichende Zeichen enthalten. Hierbei sollten komplexe Regeln durch die sequenzielle Verwendung einfacher Regeln abgebildet werden.

Dagegen werden bei einem Black-List-Ansatz solche Daten als unzulässig eingestuft und abgewiesen, die in der Liste enthalten sind. Alle Daten, die nicht explizit verboten sind, werden bei diesem Ansatz akzeptiert.

Bei dem Black-List-Ansatz besteht jedoch die Gefahr, dass nicht alle Variationen unzulässiger Daten berücksichtigt und somit erkannt werden. Daher sollte der White-List-Ansatz dem Black-List-Ansatz vorgezogen werden.

Kanonalisierung vor der Validierung

Daten können in verschiedenen Kodierungen (z. B. UTF-8, ISO 8859-1) und Notationen (z. B. bei UTF-8 ist "." = "2E" = "C0 AE") vorliegen. Abhängig vom angewendeten Kodierungsschema kann der gleiche Wert demnach unterschiedlich interpretiert werden. Findet eine Validierung der Daten ohne Berücksichtigung der Kodierung und der Notation statt, so werden gegebenenfalls schadhafte Daten nicht erkannt und gefiltert. Daher sollten alle Daten vor der Validierung in eine einheitliche, normalisierte Form überführt werden. Dieser Vorgang wird als Kanonalisierung der Daten bezeichnet. Die so dargestellten Daten werden dann weiterverarbeitet. Bei der Verwendung von AJAX sollte zudem für das Nachladen die Eigenschaft innerText anstatt von innerHTML genutzt werden, da innerText automatisch eine Enkodierung vornimmt.

Darüber hinaus sollte das Kodierungsschema bei der Auslieferung von Daten durch die Webanwendung explizit gesetzt werden (z. B. über den Content-Type-Header: charset=ISO-8859-1).

Kontextsensitive Maskierung der Daten

Falls potenziell schadhafte Daten von der Webanwendung verarbeitet werden müssen (z. B. Zeichen mit einer Bedeutung für verwendete Interpreter) und somit eine Filterung nicht durchgeführt werden kann, müssen diese Daten maskiert und so in eine andere Darstellungsform überführt werden. In dieser maskierten Form werden die Daten nicht mehr als ausführbarer Code interpretiert. Da die Maskierung Interpreter-spezifisch ist, müssen alle verwendeten Interpreter berücksichtigt werden (z. B. SQL, LDAP). Die Maskierung muss demnach kontextsensitiv für das erwartete Ein- und Ausgabeformat und die Interpretersprache durchgeführt werden. Aufgrund der Komplexität und der spezifischen Anforderungen unterschiedlicher Interpretersprachen wird empfohlen, für die Maskierung spezialisierte Bibliotheken einzusetzen.

Es sollte eine Maskierung aller Zeichen vorgenommen werden, die als unsicher für den beabsichtigten Interpreter eingestuft werden. Dazu zählen z. B.

Eine Maskierung kann durch eine Überführung der betroffenen Daten bzw. Metazeichen der jeweiligen Interpretersprache in sogenannte Zeichenreferenzen erfolgen. Das folgende Beispiel zeigt ausgewählte HTML-Zeichen mit den entsprechenden Zeichenreferenzen:

Hier ist darauf zu achten, dass &-Zeichen im ersten Durchlauf ersetzt werden, da dieses Zeichen in anderen Zeichenreferenzen als Metazeichen wiederverwendet wird.

Verwendung eines eigenen Markups zur Filterung von HTML-Tags

Falls die Webanwendung HTML-Formatierungstags in Benutzereingaben erfordert (z. B. zur Formatierung von Benutzer-Beiträgen), sollten erlaubte HTML-Tags von problematischen Tags unterschieden und gefiltert werden (siehe auch Abschnitt Kontextsensitive Maskierung der Daten).

Bei diesem Ansatz besteht das hohe Risiko, problematische Tags (beispielsweise <script>) zu übersehen. Daher sollte der alternative Ansatz, für das Markup des Benutzers eigene Markup-Tags zu definieren (z. B. BBCode), vorgezogen werden. Diese Markup-Tags werden dann von der Anwendung in die zugehörigen HTML-Tags übersetzt. Herkömmliche Tags bzw. problematische Zeichen werden nach wie vor gefiltert.

Ein mögliches Verfahren, wenn ein einfaches Markup zugelassen werden soll, ist die Verwendung von { und } statt < und >. Fett würde dann als {F}Dies ist fett{/F} geschrieben und ein Bild könnte auf diese Weise platziert: {img src=/images/img.gif width=1 height=1 img}.

Hierbei darf die Umwandlung in HTML nicht einfach geschweifte Klammern durch spitze Klammern ersetzen, sondern muss jedes Tag als Ganzes ansehen:

Wenn HTML-Tags zugelassen sind, ist grundsätzlich darauf zu achten, dass keine iFrame-Tags erlaubt sind. Mithilfe von iFrames können beliebige Inhalte in die Webseite eingefügt werden. Diese dürfen daher nicht genutzt werden können.

Behandlung von Fehleingaben (Sanitizing)

Anstatt Daten aufgrund eines unerwarteten Datenformats oder Zeichens abzulehnen, können Fehleingaben korrigiert und automatisch transformiert werden (engl. sanitize). Dadurch soll eine benutzerfreundliche Eingabe der Daten in unterschiedlichen Schreibweisen ermöglicht werden. Für eine Weiterverarbeitung lassen sich die Daten von unerwarteten Zeichen säubern (z. B. die Telefonnummer (0049)-201-12345678 kann in das nur aus Zahlen bestehende Format 004920112345678 überführt werden).

Eine Säuberung kann darin bestehen, Zeichen zu löschen, zu ersetzen oder zu maskieren (siehe auch Abschnitt Kontextsensitive Maskierung der Daten).

Beim Sanitizing besteht die Gefahr, dass Änderungen an den Daten zu einer neuen Komplexität, neuen Angriffsvektoren oder einer Missinterpretation führen. Daher sollte Sanitizing nach Möglichkeit vermieden und nur in Fällen angewendet werden, in denen ein Missbrauch des Sanitizing ausgeschlossen werden kann.

Falls die Webanwendung eine Korrektur der Daten erfordert, sollte die bewusste Manipulation von Daten (z. B. der SessionID durch einen Angreifer) nicht korrigiert, sondern abgelehnt werden. Darüber hinaus sollten Eingabedaten, die mit bestimmungsgemäßer Browser-Bedienung nicht eintreten können, grundsätzlich abgelehnt werden. Dazu zählen z. B.:

Bei einer Säuberung der Daten sollte die geschachtelte Eingabe von Angriffsvektoren berücksichtigt werden. Problematisch ist z. B. der auf den ersten Blick vernünftig erscheinende Filter s/<script>//g; (hier in Perl RegEx-Syntax geschrieben), um <script>-Tags im Eingabestrom zu löschen. Dieser kann jedoch mit einer geschachtelten Eingabe (z. B. <sc<script>ript>) umgangen werden. Es ist daher rekursiv zu filtern. Im Zweifelsfall sind die Eingabedaten abzulehnen.

Grundsätzlich sollte bei einer Ablehnung der Daten die angeforderte Aktion ebenfalls abgebrochen und eine neutrale Fehlermeldung ausgegeben werden (siehe auch M 4.400 Restriktive Herausgabe sicherheitsrelevanter Informationen bei Webanwendungen ). Bei Webanwendungen mit hohem Schutzbedarf sollte zusätzlich die Sitzung invalidiert werden.

Prüffragen: