Bundesamt für Sicherheit in der Informationstechnik

M 4.393 Umfassende Ein- und Ausgabevalidierung bei Webanwendungen und Web-Services

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

Verantwortlich für Umsetzung: Administrator, Entwickler

Alle an eine Webanwendung oder einen Web-Service ü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 oder an nachgelagerte Systeme wie zum Beispiel Datenbanken gefiltert und transformiert (output encoding) werden. Entsprechendes gilt für die Aufrufparameter und Rückgabewerte von Web-Services. Dadurch wird sichergestellt, dass nur erwartete und keine schadhaften Daten 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 der Umsetzung und der Konfiguration der Validierungskomponente berücksichtigt werden:

Identifizierung der Daten

Damit die Ein- und Ausgabedaten umfassend validiert werden können, müssen zunächst alle zu verarbeitenden Datenstrukturen (zum Beispiel 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 (zum Beispiel 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 zum Beispiel personenbezogene Daten (Name, Telefonnummer, Postleitzahl), Bilder, PDF-Dateien und formatierte Texte. Typische Interpreter für Daten, die von Webanwendungen und Web-Services verarbeitet oder ausgegeben werden, sind zum Beispiel HTML -Renderer, SQL -, XML -, JSON -, 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 oder Web-Services 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 (zum Beispiel SQL -Syntax) bei unterschiedlichen Produkten variieren. Beispiele für kritische Zeichen werden im Abschnitt Potenziell gefährliche Zeichen für Interpreter in Hilfsmittel zum Baustein Webanwendungen aufgeführt.

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

  • Namen von Form-Variablen (Sie können ebenso wie der Wert der Form-Variablen beliebig manipuliert werden),
  • HTTP -Header-Felder (Header-Felder in HTTP -Requests und -Responses sollten ausschließlich ASCII -Zeichen enthalten und zum Beispiel keine Zeilenvorschubzeichen wie \r\n),
  • Session-ID s (zum Beispiel aus Cookies).

Automatisierte Aufrufe durch den Client zum Beispiel durch Ajax- beziehungsweise 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.

Schadhafter Code kann aber auch über einen Weg übermittelt werden, der nicht von der Webanwendung oder dem Web-Service kontrolliert werden kann (zum Beispiel FTP , NFS ). Kann ein Angreifer über diese Dienste Dateien ändern oder erzeugen, die von der Webanwendung oder dem Web-Service 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 vor der Ausgabe an die Benutzer oder der Weiterverarbeitung durch die Anwendung validiert werden.

Serverseitige Validierung

Üblicherweise greifen die Benutzer mit generischen Clients (zum Beispiel Web-Browser) auf die Webanwendung zu. Diese Clients befinden sich nicht im Sicherheitskontext der Webanwendung, sondern stehen unter der Kontrolle der Benutzer. In gleicher Weise kann sich auch ein Web-Service nicht darauf verlassen, dass die aufrufende Anwendung die Daten überprüft hat. 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 (zum Beispiel 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.

Kanonisierung vor der Validierung

Daten können in verschiedenen Kodierungen (zum Beispiel UTF-8, ISO 8859-1) und Notationen (zum Beispiel 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 Kanonisierung der Daten bezeichnet. Die so dargestellten Daten werden dann weiterverarbeitet. Bei der Verwendung von AJAX sollte zudem für das Nachladen die Eigenschaft textContent anstatt von innerHTML genutzt werden, da textContent automatisch eine Enkodierung vornimmt.

Darüber hinaus sollte das Kodierungsschema bei der Auslieferung von Daten durch die Webanwendung explizit gesetzt werden (zum Beispiel über den Content-Type-Header: charset= ISO -8859-1). Auch bei Web-Services sollten die verwendeten Kodierungen den Client-Systemen mitgeteilt werden, beispielsweise in den entsprechenden XML -Tags.

Kontextsensitive Maskierung der Daten

Falls potenziell schadhafte Daten von einer Webanwendung oder einem Web-Service verarbeitet werden müssen (zum Beispiel 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 (zum Beispiel 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 zum Beispiel:

  • unerwartetes JavaScript und HTML zur Auslieferung an den Client (zum Beispiel den Web-Browser),
  • unerlaubt eingefügte SQL -Statements an die Datenbank (zum Beispiel aus Eingaben in Formularfeldern),
  • Befehle an das Betriebssystem (zum Beispiel in manipulierten HTTP -Variablen).

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

  • & => &
  • < => &lt;
  • > => &gt;
  • " => &quot;
  • ' => &#39;

Hier ist darauf zu achten, dass &-Zeichen im ersten Durchlauf ersetzt werden und dass keine Mehrfach-Maskierung erfolgt, 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 (zum Beispiel 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. Auch scheinbar harmlose Tags lassen sich teilweise über Attribute wie "onMouseOver" zur Ausführung von Code missbrauchen. Daher sollte der alternative Ansatz, für das Markup des Benutzers eigene Markup-Tags zu definieren (zum Beispiel BBCode), vorgezogen werden. Diese Markup-Tags werden dann von der Anwendung in die zugehörigen HTML -Tags übersetzt. Herkömmliche Tags beziehungsweise 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 werden: {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:

  • {img nach <img,
  • img} nach >,
  • src=Datei nach src="Datei" (wobei Datei zusätzlich zu filtern ist).

Wenn HTML -Tags zugelassen sind, ist grundsätzlich darauf zu achten, dass mindestens die folgenden Tags nicht erlaubt sind:

  • applet
  • base
  • iframe
  • link
  • object
  • script
  • style

Mithilfe dieser Tags können beliebige Inhalte in die Webseite eingefügt werden. Diese dürfen daher nicht genutzt werden können.

Abwehr von Code-Injection in SOAP -Nachrichten

Allgemein sollten nie Eingaben ohne vorherige Prüfung weitergegeben werden. Um Injection-Angriffe zu vermeiden, ist es notwendig, Eingabeparameter aus der Schnittstellenbeschreibung ( WSDL -Datei) heraus auf schädlichen Code zu filtern und zum Beispiel über eine Whitelist nur systemkonforme Strings zuzulassen. Empfohlen wird außerdem, Strings als Eingabetyp möglichst komplett zu vermeiden und zudem Integer-Werte auf deren Länge zu überprüfen.

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 (zum Beispiel 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 oder der Web-Service fehlerhafte Daten erkannt hat, sollten Fehler, die auf eine bewusste Manipulation hindeuten (zum Beispiel eine veränderte Session-ID) nicht automatisch korrigiert, sondern abgelehnt werden. Darüber hinaus sollten Eingabedaten, die mit bestimmungsgemäßer Browser- beziehungsweise Client-Bedienung nicht eintreten können, grundsätzlich abgelehnt werden. Dazu zählen zum Beispiel:

  • Zusätzliche oder fehlende Formular-Parameter,
  • Session-Cookies mit unerwarteten Zeichen oder ungültiger Länge,
  • Unerwartete Werte bei der Übertragung von Formular-Parametern aus vordefinierten HIDDEN-, SELECT- oder CHECKBOX-Feldern,
  • Abweichender oder unerwünschter Übertragungsweg der Parameter (zum Beispiel GET, POST, Cookie).

Bei einer Säuberung der Daten sollte die geschachtelte Eingabe von Angriffsvektoren berücksichtigt werden. Problematisch ist zum Beispiel 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 (zum Beispiel <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 und Web-Services ). Bei Webanwendungen oder Web-Services mit hohem Schutzbedarf sollte zusätzlich die Sitzung invalidiert (abgebrochen) werden.

Prüffragen:

  • Werden alle Daten (Ein- und Ausgabedaten) und Datenströme der Webanwendung oder des Web-Service (zum Beispiel zwischen Benutzer, Webanwendung, Clientsystemen und Hintergrundsystemen) bei der Validierung berücksichtigt?

  • Werden auch Sekundärdaten (wie beispielsweise Session-IDs) bei der Validierung berücksichtigt?

  • Führt die Webanwendung oder der Web-Service eine serverseitige Validierung der Daten auf einem vertrauenswürdigen IT-System durch?

  • Führt die Webanwendung oder der Web-Service vor der Validierung eine Kanonisierung der Daten durch?

  • Findet in der Webanwendung oder dem Web-Service eine kontextsensitive Validierung der Daten unter Berücksichtigung des erwarteten Interpreters der Daten statt?

  • Bei Webanwendungen/Web-Services mit automatischer Behandlung von Fehleingaben (engl. Sanitizing): Wird die Behandlung von Fehleingaben sicher umgesetzt?

  • Wird die Art der Eingabedaten geprüft?

  • Sind bestimmte Eingabetypen ausgeschlossen?

Stand: 15. EL Stand 2016