Zielgruppe BetriebVersion: GSB10.1Fehlermeldungen

Bei der Behandlung von ungültigen Eingaben kann zwischen zwei Fällen unterschieden werden:

• Fehleingaben des Benutzers,
• bewusste Manipulation.

Im ersten Fall ist – unter Wahrung des Minimalitätsprinzips – in benutzerfreundlicher Weise zu reagieren. Der Benutzer ist auf den Fehler hinzuweisen und bei der Korrektur entsprechend zu führen.

Im zweiten Fall sollte die Reaktion in geeigneter Weise den Manipulationsversuch abwehren. Dann ist zu entscheiden, ob eine Filterung erfolgt oder ob die Weiterverarbeitung abgelehnt wird.

ErrorMessages

Zur Validierung von Eingabedaten in Formularen stellt der GSB so genannte Formular-Validatoren bereit. Diese Validatoren prüfen die Eingaben auf ihre Zulässigkeit und geben entsprechende Fehlermeldungen (ErrorMessages) zurück.

Die Fehlermeldungen können beim GSB mandanten-spezifisch angepasst werden. Jede Fehlermeldung wird durch einen eindeutigen Dokumentnamen identifiziert. Der eigentliche Fehlertext wird dann im zugehörigen Dokument hinterlegt. Die Fehlermeldungen befinden sich innerhalb des GSB-Redaktionssystems im Ordner

<Mandant>/_config/ResourceBundleEntries/ErrorMessages

Beispiele

Der StringLengthValidator dient in Formularen dazu, die Länge eines Eingabetexts in Formularfeldern zu überprüfen. Der eingegebene Wert darf die im Validator-Parameter maxLength angegebene Länge nicht überschreiten und die im Validator-Parameter minLength angegebene Länge nicht unterschreiten.

Die Fehlermeldungen StringTooLong und StringTooShort werden ausgegeben, falls die Mindestlänge unterschritten bzw. die maximale Länge überschritten wurde.

Die Angaben der Fehlermeldung sollten bei einem Mandanten in Abhängigkeit des eingesetzten Kontextes geprüft werden: Die Fehlermeldung StringTooLong könnte beispielsweise wie folgt aufgebaut werden:

Der Text ist zu lang!Der Text darf höchstens {0} Zeichen enthalten.

wobei der Parameter {0} die Zeichenlänge des Validators in die Fehlermeldung einblendet. Für die Überprüfung der Betreff-Zeile im Kontaktformular ist die Ausgabe

Der Text ist zu lang!Der Text darf höchstens 80 Zeichen enthalten.

für den Benutzer sicher hilfreich. Für andere Eingabefelder, etwa bei Passwörtern sind weniger Informationen etwa in der Form

Der Text ist zu lang!

unter Umständen empfehlenswerter, um einen Angreifer keine weiteren Informationen zu liefern.

Hinweise und Maßnahmen

Die GSB-Fehlermeldungen sind entsprechend des mandanten-spezifischen Ausgabekontextes zu überprüfen und ggf. nach den mandanten-spezifischen Anforderungen anzupassen.

Fehlerseiten

Der GSB-Webserver liefert beim Erkennen von Fehlersituationen automatisch die zugehörigen Fehlerseiten aus. Diese Seiten können frei gestaltet werden. Dabei ist darauf zu achten, dass keine unnötigen Informationen in der Fehlerseite enthalten sind, insbesondere keine Pfadnamen. Außerdem ist sicherzustellen, dass keine Eingabedaten (templateIDs, URL oder HTTP-Header) ausgegeben werden.

Hinweise und Maßnahmen

Im GSB-Redaktionssystem müssen unter dem Pfad

/common/ErrorPageYYY

in entsprechenden Fehlerdokumenten mandantenspezifische Fehler-Seiten registrieren werden.

Neben den bereits vorkonfigurierten Fehlerseiten für die Fehlercodes

• 403 (Access Denied),
• 404 (Resource not found)
• 500 (Internal Server Error)

können für weitere Fehlercodes zusätzliche Seiten angelegt werden (vgl. GSB-Dokumentation: Basiskonfiguration_Mandant).

Darüber hinaus können durch einen Angreifer Fehlersituationen durch die Angabe von fehlerhaften bzw. nicht vorhandenen Darstellungstemplates verursacht werden. Diese Fehler-Situation wird in den GSB-Standardtemplates durch die so genannte doesNotUnderstand.jsp abgefangen und bearbeitet. Bei der Anpassung dieses Darstellungstemplates an das mandanten-spezifische Layout sind neben den oben erwähnten Maßnahmen unter Umständen auch die in den nächsten Kapiteln skizzierten Optionen zu berücksichtigen.

Weitere Maßnahmen

In dem Dokument „Sicherheit von Webanwendungen – Maßnahmenkatalog und Best Practices“ empfiehlt das BSI ergänzende Maßnahmen einzuführen, deren Einsatz aber zunächst in Abhängigkeit der Anwendung auf Angemessenheit geprüft werden sollte. Als mögliche Reaktionen auf Manipulationsversuche können je nach Situation beispielsweise folgende Maßnahmen ergriffen werden:

• Die weitere Verarbeitung ist zu stoppen. Unter Umständen ist es möglich bzw. sinnvoll, statt einer Fehlermeldung eine Reaktion wie folgt vorzunehmen:

• Dem Benutzer – dem in diesem Fall ein Angriff unterstellt wird – wird der korrekte Umgang mit der Eingabe vorgetäuscht, um seinen Angriffsversuch zu unterlaufen und weiteres Suchen nach Schwachstellen zu erschweren. So würde die Antwort auf das manipulierte Absenden eines Kontaktformulars beispielsweise genauso wie im korrekten Fall lauten: "Vielen Dank für Ihre Anfrage, die wir umgehend bearbeiten."

• Es ist zur Homepage oder Sitemap oder der (neutralen) Seite zurückzukehren, die auch bei Zugriffen auf nicht vorhandene Seiten angezeigt wird.
• Es ist eine explizite Warnung auszugeben, dass ein Angriffsversuch festgestellt worden ist und dass alle Zugriffsversuche protokolliert werden bzw. anderweitige Maßnahmen ergriffen werden.

Welche Maßnahmen an welcher Stelle der Bearbeitung einzuleiten sind, kann nur in Abhängigkeit einer konkreten Anwendung entscheiden werden. Diese Maßnahmen müssen daher auf Basis der verfügbaren GSB-Bausteine innerhalb der Mandanten-Projekte konzipiert und umgesetzt werden.