Zielgruppe BetriebVersion: GSB10.1Formulare

Die Validierung der Eingabedaten (Input-Validierung) sollte erfolgen, bevor die Daten zum Zugriff auf Subsysteme genutzt werden. Die Validierung der Eingabedaten geschieht im Wesentlichen zur Verhinderung von Injection-Angriffen.

Im Vorfeld zur Prüfung der Formulardaten/RequestParameter empfiehlt sich darüber hinaus eine Filterung auf dem Webserver durch Einsatz des Apache-Moduls mod_security.

Validatoren

Zur Validierung von Formulardaten stellt der GSB so genannte Formular-Validatoren zur serverseitigen Überprüfung von Eingabedaten bereit. Zur Zeit existieren im GSB die folgenden Validator-Klassen, die innerhalb eines Formularfeld-Validators (Originalname: HFItemValidator) eingesetzt werden können:

Name	Beschreibung
IntegerValidator	Der eingegebene Wert muss eine gültige Integer-Zahl sein.
LongValidator	Der eingegebene Wert muss eine gültige Long-Zahl sein.
DoubleValidator	Der eingegebene Wert muss eine gültige Double-Zahl sein.
StringLengthValidator	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.
DateValidator	Der eingegebene Wert muss ein gültiges Datum sein. Das Format kann im Validator-Parameter formatString in der SimpleDateFormat-Syntax angegeben werden. Der Default-Wert ist "TT.MM.JJJJ". Weitere Konfigurationsmöglichkeiten betreffen Vergleiche und zu ignorierende Default-Werte.
AllowedValueValidator	Der eingegebene Wert muss mit den zulässigen Werten übereinstimmen. Die zulässigen Werte werden im Validator-Parameter allowedValues in einer Komma-separierten Liste angegeben.
EmailValidator	Der eingegebene Wert muss eine gültige Email-Adresse sein. Validiert wird mithilfe von org.apache.commons.validator.EmailValidator
PasswordValidator	Prüft ein eingegebenes Passwort auf einige Minimal-Anforderungen (eine Länge von mindestens acht Zeichen, mindestens ein Großbuchstabe, mindestens ein Kleinbuchstabe und mindestens eine Ziffer).
RegexValidator	Prüft den eingegebenen Wert auf einen regulären Ausdruck. Dieser muss in der Validator-Property regex angegeben werden. Der Fehlercode kann in der Property errorCode festgelegt werden. Der Default-Wert ist illegalRegexValue.
InverseRegexValidator	Prüft den eingegebenen Wert darauf, dass er einem regulären Ausdruck nicht entspricht. Der reguläre Ausdruck muss in der Validator-Property regex angegeben werden. Der Fehlercode kann in der Property errorCode festgelegt werden. Der Default-Wert ist illegalRegexValue.
NotDefaultValueValidator	Stellt sicher, dass der eingegebene Wert nicht gleich dem Default-Wert des Formular-Elements ist. Dieser Validator steht nur bei HFTextInput-Elementen zur Verfügung.
OneOfMandatoryValidator	Dieser Validator stellt sicher, dass mindestens eines der konfigurierten Formular-Elemente ausgefüllt wurde.
RegexMandatoryValidator	Prüft den Wert des in der Validator-Property checkElement verlinkten Formularelements auf den in der Validator-Property regex angegebenen regulären Ausdruck.
ValueHashValidator	In den Default-Templates wird zu versteckten Formularfeldern (HFTextInputField mit Typ 1=hidden) automatisch ein zweites verstecktes Feld mit dem Suffix .HASH und einem Hash-Wert generiert. Dieser Wert kann von diesem ValueHashValidator überprüft werden. Falls der Hash-Wert nicht übereinstimmt, liefert er den Fehlercode illegalParamHash mit dem Namen und dem Wert des Request-Parameters als Parameter. Der Fehlercode lässt sich über die Validator-Property errorCode überschreiben. Da Hidden-Felder betroffen sind, wird der Fehlercode global für das gesamte Formular gesetzt. Die Überprüfung der versteckten Formularfelder funktioniert standardmäßig nur dann korrekt, wenn die Formularfeld-Property useFixDefaultValue auf 1 steht. Falls diese Einstellung nicht vorgenommen wurde, funktioniert die Überprüfung nur beim ersten Versuch, da sonst der gefälschte Wert aus dem Request als gültiger Default-Wert angesehen wird.
ShoppingCartValidator	Spezieller Validator für den Warenkorb. Überprüfbar sind die minimale und maximale Bestellsumme sowie Mindest- und Maximalmengen für einzelne Dokumente.

Mithilfe dieser Validator-Klassen können einfache, anwendungsabhängige Filter erstellt werden, die dann durch sequenzielle Verwendung zu Formular- bzw. Formularbaustein-spezifischen komplexeren Filter zusammengebaut werden können.

Hinweise und Maßnahmen

Die bereits vorhandenen Formulare sollten hinsichtlich ihres Schutz- und Validierungsbedarfs überprüft werden, um beispielsweise durch die Erstellung geeigneter, anwendungsspezifischer Validatoren oder durch die Anwendung bereits vorhandener Validatoren die Möglichkeit von Buffer Overflow, XSS oder SQL-Injection Attacken auszuschließen bzw. zumindest deutlich zu erschweren.

In den folgenden drei Kapiteln werden exemplarisch Validierungsmöglichkeiten für Textfelder, Auswahlfelder, Radiobuttons und Checkboxen sowie versteckte Felder skizziert.

Textfelder

Textfelder können sowohl einzeilig als auch mehrzeilig sein. Sie können mit einem Text vorbelegt werden. Zur Absicherung der Text-Eingabefelder bei Formularen sollten die Eingabefelder auf ihren Datentyp, minimale und maximale Eingabelängen bzw. -größe beschränkt werden. Darüber hinaus können die einzelnen Felder auf diejenigen Zeichen beschränkt werden, die beim Zugriff auf Subsysteme potenziell gefährlich werden könnten (Blacklist-Ansatz), bzw. die als erlaubte Zeichen gelten (Whitelist-Ansatz).

Die Zeichentabelle ist für jedes Subsystem und die jeweilige Art der Verwendung anzupassen. Grundsätzlich gilt:

• Whitelisting ist dem Blacklisting vorzuziehen, wann immer möglich.
• Beim Whitelisting ist zunächst von einer möglichst kleinen Zeichenmenge auszugehen, die dann individuell erweitert wird.

Beispiel 1

In einem Adressformular könnte das Eingabefeld für deutsche Postleitzahlen zunächst mithilfe des Attributes maximale Länge (Originalname maxLengthAttribute) beschränkt werden. Danach kann nach dem Whitelist-Ansatz beispielsweise mithilfe eines RegexValidator-Dokuments und dem regulären Ausdruck

^[0-9]{5}$

die Benutzereingabe serverseitig geprüft werden. Dieser reguläre Ausdruck lässt nur fünfstellige Zahlen, d. h. insbesondere keine Leerzeichen oder Buchstaben zu. Durch diesen Validator werden Datentyp, Eingabelänge und zulässige Zeichen überprüft.

Analog könnten beispielsweise die zulässigen Zeichen einer Telefonnummer mit Hilfe des regulären Ausdrucks

^[0-9\+\(\)\-\.\/]*$

geprüft werden.

Beispiel 2

Um beim Kommentar-Eingabefeld eines Kontaktformulars unzulässige Zeichen nach dem Blacklist-Ansatz auszuschließen, könnte bspw. der reguläre Ausdruck

^[^\\x00-\\x09\\x0b\\x0c\\x0e-\\x1f]*$

eingesetzt werden. Der reguläre Ausdruck schließt alle Zeichen des ASCII-Codes unter 0-31 mit Ausnahme von Zeilenumbrüchen aus.

Durch den Einsatz eines weiteren StringLengthValidator-Dokuments, der vor der Prüfung auf unzulässige Zeichen integriert werden sollte, könnte die maximale Länge des Kommentarfelds beispielsweise auf 1024 Zeichen beschränkt werden.

Auswahlfelder, Radiobuttons und Checkboxen

Mithilfe von Auswahlfeldern, Radiobuttons und Checkboxen werden dem Besucher des Webauftritts meist vordefinierte Werte zur Auswahl angeboten:

• Auswahlfelder können einzeilig sein, dann erfolgt die Auswahl per so genannter "Drop Down-Liste". Sind sie mehrzeilig, können sie auch so definiert werden, dass mehr als ein Eintrag ausgewählt werden kann. Einträge können dabei vorselektiert werden.
• Radiobuttons dienen dazu, eine von mehreren Optionen auszuwählen. Sie haben dabei dieselbe Funktionalität wie Auswahlfelder mit einer Selektierungsmöglichkeit. Eine Option einer Auswahlgruppe sollte immer vorselektiert sein. Ansonsten kann es passieren, dass ein Formular abgesendet wird, ohne dass eine Option ausgewählt wurde.
• Checkboxen sind Ja/Nein-Felder (angekreuzt/leer). Sind mehrere Checkboxen vorhanden, können beliebig viele angekreuzt sein. Sie entsprechen dann mehrzeiligen Auswahlboxen mit mehreren Selektierungsmöglichkeiten.

Zur Absicherung von Auswahlfeldern, Radiobuttons und Checkboxen bei Formularen sollten diese serverseitig explizit auf die Eingabe zulässiger Werte geprüft werden.

Beispiel

Bei zielgruppen-orientierten Formularen kann es beispielsweise sinnvoll sein, dass den Benutzern in Abhängigkeit der Zielgruppe jeweils andere Werte zur Auswahl angeboten werden.

Im folgenden Beispiel wird ein Newsletter an die Zielgruppen „intern“ und „extern“ versendet. Externe Abonnenten können die Themen

• Innenpolitik
• Außenpolitik

auswählen. Interne Benutzer haben zusätzlich noch die Möglichkeit, das Thema „Interne Nachrichten“ auszuwählen.

Ein Angreifer, der den Newsletter für „Externe Abonnenten“ abonniert hat, könnte ggf. das für ihn nicht zulässige Thema „Interne Nachrichten“ erraten und durch Manipulationen des zugehörigen Auswahlfelds „subjects“ im Formular diesen Wert zusätzlich einbringen. Mithilfe eines AllowedValueValidator-Dokuments für das Auswahlfeld „subjects“ könnte diese Manipulation verhindert werden, indem für die beiden Zielgruppen unterschiedliche Werte angeboten werden. Mit der Angabe im Parameter-Feld

allowedValues=Innenpolitik, Aussenpolitik

würde im Formular für „Externe Abonnenten“ dann severseitig sichergestellt, dass der Wert Interne Nachrichten in diesem Formular als nicht zulässig abgewiesen würde, während im Formular für „Interne Abonnenten“ der entsprechende Validator im Parameter-Feld die Angabe

allowedValues=Innenpolitik, Aussenpolitik,

• Interne Nachrichten

enthalten müsste, um den internen Abonnenten in diesem Formular die zulässigen Themen vollständig anbieten zu können.

Versteckte Felder

HTML-Formulare können nicht nur die sichtbaren Elemente, wie Textfelder, Auswahlboxen, Radiobuttons, Checkboxen und Buttons haben, sondern auch versteckte Felder. Diese Formularelemente haben – wie alle Formularelemente – einen Namen, dem ein Wert zugewiesen wird. Der Wert wird üblicherweise schon bei der Generierung des Quelltextes für das Formular am Server gesetzt, damit ist er im HTML-Quelltext enthalten. Sieht man sich den Quelltext im Browser an, so kann man auch den Wert des „versteckten Feldes“ erkennen. Angreifer könnten dieses Feld für Manipulationen nutzen, wenn es nicht weiter abgesichert wird.

Beispiel

Ein verstecktes Feld kann im GSB mithilfe eines Textfeld-Dokuments (Originalname HFTextInputField) eingerichtet werden. In diesem Dokument muss das Attribut Typ (Originalname typeAttribute) auf den Wert hidden (bzw. 1) sowie das Attribut Read Only (Originalname useFixDefaultValue) auf den Wert true (bzw. 1) gesetzt werden.

In den GSB-Standardtemplates wird für ein verstecktes Formularfelder automatisch ein zweites verstecktes Feld mit dem Suffix .HASH und einem Hashwert generiert. Dieser Wert kann vom ValueHashValidator überprüft werden. Falls der Wert im versteckten Feld nicht mit dem Hash-Wert übereinstimmt, liefert der Validator den Fehlercode illegalParamHash, und die Bearbeitung des Formulars wird abgebrochen.

POST und GET

Die Ausnutzung einer XSS-Lücke ist dann am einfachsten durchführbar, wenn der manipulierende Code an den Aufruf eines Links angehängt werden kann. Beispielsweise lässt sich dann ein Session Riding-Angiff in einem IMG-Tag verstecken und unbemerkt ausführen. Ähnliches gilt für andere Angriffsformen.

Möglich ist dies immer dann, wenn der Request von der Anwendung als GET-Request behandelt wird. Verwendet die Anwendung an dieser Stelle jedoch die POST-Methode, ist ein Einbau in den URL (zumindest mit einfachen Mitteln) nicht mehr möglich.

Hinweise und Maßnahmen

Es empfiehlt sich daher, HTML-Forms per POST-Methode zu übertragen, so dass im Falle einer vorhandenen XSS-Lücke wenigstens eine kleine zusätzliche Hürde gesetzt wird.

Zur Einstellung der Übertragungsmethode bei einem HTML-Formular (Originalname des Dokumenttyps: HFForm) muss das zugehörige Attribut method (Originalname: methodAttribute) den zugehörigen Wert "POST" annehmen.

Falls der Einsatz der GET-Methode ausgeschlossen werden soll, muss entweder ein ggf. vorhandenes Auswahlmenü im Editor angepasst oder der Editor um einen entsprechenden Validator für dieses Eingabefeld erweitert werden, der die Auswahl der GET-Methode als nicht zulässig zurückweist. Darüber hinaus ist auch ein Einsatz eines entsprechenden Field-Initializers zur Umsetzung der Anforderung denkbar: Wenn das Feld methodAttribute bei der Erzeugung eines HTML-Formular immer mit dem "POST" belegt und der Editor-Konfiguration ausgeblendet wird, kann das Feld methodAttribute durch einen Redakteur nicht mehr geändert werden.

Verschlüsselte Kommunikation

Eingabedaten (auch Passwörter!) werden beim normalen HTTP-Protokoll trotz ggf. verdeckter Eingabe im Klartext über das Internet übertragen. Für eine verschlüsselte Kommunikation zwischen Browser und Server sollte das SSL-Protokoll eingesetzt werden, das im Browser automatisch durch HTTPS initiiert wird. Es gewährleistet, dass Daten während der Übertragung nicht gelesen oder manipuliert werden können.

Aus diesem Grund sollten sämtliche personenbezogenen bzw. sicherheitsrelevanten Formularfelder verschlüsselt übertragen werden.

Hinweis: Da hier nur der Kommunikationsweg abgesichert wird, könnte eine Attacke, die beispielsweise mit Hilfe eines Trojaners auf dem Rechner eines Benutzers durchgeführt wird, trotz HTTPS-Verbindungen weiterhin erfolgreich Eingabedaten oder Passworte des Benutzers ausspähen.

Hinweise und Maßnahmen

Zur Einstellung der Übertragungsmethode bei einem HTML-Formular (Originalname des Dokumenttyps: HFForm) muss das zugehörige Attribut method (Originalname: methodAttribute) den zugehörigen Wert "POST SSL" oder „GET SSL“ annehmen.

Um die gesamte HTML-Seite verschlüsselt auszuliefern, müssen am Navigationsknoten ebenfalls entsprechende Einstellungen durchgeführt werden.

Fehlermeldungen

Die in den Formularen eingesetzten Validatoren prüfen die Eingaben auf ihre Zulässigkeit und geben ggf. entsprechende Fehlermeldungen zurück. Bei der Gestaltung dieser Fehlermeldung sind prinzipiell zwei divergierende Ziele zu verfolgen: Auf der einen Seite sind diese Fehlermeldungen so ausführlich und benutzerfreundlich zu gestalten, dass ein Benutzer bei einem Fehler eine qualifizierte Meldung erhält und weiß, welche Maßnahmen er zur Fehlerbehebung durchführen muss. Auf der anderen Seite sollten diese Fehlermeldung einem potenziellen Angreifer keine zusätzlichen Informationen liefern, um einen Angriff gezielt vorbereiten zu können.

Das nachfolgende Beispiel versucht, die Problematik zu verdeutlichen.

Beispiel

Bei einem geschlossenen Benutzerbereich, der mit einer „Passwort vergessen“-Funktion ausgestattet ist, können sich Benutzer nach der Angabe des Login-Namens ein neues Passwort über sicheren Kommunikationskanal automatisch bereitstellen lassen.

Falls nun ein registrierter Benutzer sich bei seinem Login-Namen vertippt, wäre es aus Benutzersicht wünschenswert, die Meldung zu erhalten, dass kein Eintrag mit dem angegebenen Name registriert ist. Der Benutzer kann dann den Namen korrigieren und sich das Passwort zusenden lassen. Aus Sicherheitsgründen ist es jedoch eher empfehlenswert, statt einer Fehlermeldung eine Erfolgsmeldung zu versenden (etwa „Sie erhalten in Kürze ein neues Passwort“), damit ein Angreifer nicht mittels der „Passwort vergessen“-Funktion existierende Login-Namen erraten kann.

Denial of Service

Ein Formular stellt den Besuchern eines Webauftritts in der Regel bestimmte Applikationslogiken zur Verfügung, die mithilfe der im Formular übergebenen Eingabedaten ausgeführt werden. Such- oder Kontaktformulare sind einfache Beispiele, die zu DoS-Angriffen genutzt werden könnten:

• Ein Angreifer könnte beispielsweise mittels eines Skripts über das Kontaktformular eine große Anzahl von Emails generieren und die Mailbox der Kontaktperson überfluten.
• Ebenso könnte ein Angreifer mittels eines Skripts über das Suchformular eine größere Anzahl von Suchanfragen erzeugen und so zunächst die Verfügbarkeit der Suchmaschine einschränken und ggf. auch den gesamten Webauftritt schwer erreichbar bzw. vollständig unzugänglich machen.

Hinweise und Maßnahmen

Um DoS-Attacken bei Formularen zu erschweren, stehen – neben allgemeinen Maßnahmen – im GSB-Umfeld verschiedene Projektlösungen zur Verfügung.

Captchas

Beim Verfahren der Captchas (Completely Automated Public Turing Test to Tell Computers and Humans Apart) wird dem Benutzer innerhalb des Formulars ein Bild gezeigt, welches z. B. eine mit Störungen versehene Zeichenkette enthält, die von einem Menschen noch zu erkennen ist, von einer Maschine aber nicht mehr erkannt bzw. automatisch ausgelesen werden kann. Das Bild bzw. die enthaltene Zeichenkette wird bei jedem Aufruf des Formulars mithilfe eines Zufallsgenerators neu erzeugt. Die korrekte Eingabe der Zeichenkette schaltet die Sperrung wieder frei. Bei der Verwendung von Captchas sollte berücksichtigt werden, dass diese in der Regel nicht Barrierefrei umgesetzt werden können.

Auf einer Website, die ein Formular bereitstellt, das eine Bearbeitungsaktion im Backend auslöst oder Email verschickt (bspw. Kontakt-, Seite empfehlen- oder Warenkorb-Formular), könnte ein Captcha eingesetzt werden, so dass dieses Formular nur nach korrektem Ausfüllen und Absenden der Abfrage die dafür vorgesehene Aktion durchführt bzw. die gewünschte Email verschickt. Ein skript-basierter Angriff auf das Formular kann dann nicht mehr auf die oben beschrieben Weise durchgeführt werden.

Zeitverzögerungen

Durch eine Zeitverzögerung kann nach dem „Abschicken“ eines Formulars die Bearbeitungszeit des Formulars künstlich verlängert werden. Die für die Ausführung eines einzelnen Zugriffs benötigte Zeit wird dabei so weit in die Länge gezogen, dass der Angreifer innerhalb eines vernünftigen Zeitraums nicht die benötigte Anzahl an Zugriffen durchführen kann. Die Herausforderung an dieser Stelle ist, Art und Dauer der Verzögerung so zu gestalten, dass sie vom legitimen Benutzer nicht als übermäßig störend empfunden wird.

Mithilfe der Zeitverzögerung können unter Umständen die Auswirkungen eines Angriffs soweit reduziert werden, dass die Attacke in der geplanten Form für den Angreifer uninteressant werden könnte.

Bearbeitungslimits

Um einen Server durch eine von einem Angreifer erzeugte Lastsituation zu schützen, können Bearbeitungslimits für externe Anfragen eingeführt werden. Die Bearbeitungslimits schränken die Anzahl der gleichzeitig von einem Server bearbeiteten externen Anfragen ein. Wenn die Grenze der zulässigen, gleichzeitig zu bearbeitenden externen Anfragen überschritten wird, liefert der Server dem Benutzer, der eine externe Anfrage ausgelöst hat, eine einfache Fehlermeldung, statt die angeforderte, komplexe Berechnung durchzuführen.

Mithilfe der Bearbeitungslimits kann die Anzahl der Anfragen, die ein Angreifer erzeugen muss, um den Server zu überlasten, unter Umständen so hoch gesetzt werden, dass die Attacke in der geplanten Form für den Angreifer uninteressant werden könnte.

CSRF-Zugriffsschutz

Cross-Site-Request-Forgery-Angriffe oder Session-Riding-Attacken sind problematisch, da der Angreifer eine vorhandene Session des Opfers für einen Angriff nutzen kann. Details zu CSRF finden sich auf bzw. auf

Ein Schutz vor CSRF wird über ein Shared-Secret-Token realisiert, welches in der Session und in den Formularen oder Links gespeichert wird. Beim Abschicken eines Formulars werden die beiden Token (Formular, Session) verglichen. Stimmen sie nicht überein, so handelt es sich um einen Angriff.

Im GSB wird der Schutz für einzelne Formulare konfiguriert (Property „HFForm.csrfProtection“).

Beim Rendern des Formulars wird das Token aus der Session gelesen, bzw. wird beim ersten Zugriff ein Token erzeugt und in der Session gespeichert.

Beim Abschicken eines geschützten Formulars wird das Formular- mit dem Session-Token verglichen. Stimmen die Token nicht überein, wird dies als Attacke gewertet. Das Abschicken des Formulars wird verhindert, dem Nutzer wird eine Fehlerseite präsentiert. So wird sichergestellt, dass ein Angreifer eine vorhandene Session eines Opfers nicht für eine unberechtigte Ausführung von Formular gestützten Aktionen nutzen kann.

Funktionsweise

In jedem geschützten Request wird ein versteckter Parameter mit einem Token mitgesendet. Dieser wird im HFForm-Template renderStandardHiddenFields erzeugt, sofern die Property csrfProtection einen Wert > 0 hat.

Wenn die HFForm-Property csrfProtection den Wert 1 hat, wird das Token beim ersten Rendern eines betroffenen Formulars erzeugt und in der Benutzersession gespeichert. Es wird dann für alle Formulare dieser Session verwendet.

Wenn die HFForm-Property csrfProtection den Wert 2 hat, wird das Token statt in der Session im Cookie mit dem Namen csrfToken gesucht. Dieses kann es durch ein clientseitiges Javascript gesetzt worden sein (Stichwort "Double Submit Cookies"). Dieses Verfahren wird jedoch nicht empfohlen, da es keinen echten Schutz bietet.

Wenn die HFForm-Property csrfProtection den Wert 3 hat, wird das Token in der Datenbank gesucht. Gültige Tokens werden anschließend aus der Datenbank gelöscht. Daher können sie im Gegensatz zu den Session-Tokens nur ein einziges Mal genutzt werden. Datenbank-Tokens sind mit einem Erstellungs-Datum versehen, das bei Bedarf von der ValidateTimedTokenAction ausgewertet werden kann.

Nach dem Absenden des Formulars wird vom Formular-Framework (Klasse CmsActionForm) geprüft, ob das Formular wirklich von der aktuellen Benutzersession abgesendet wurde. Das ist genau dann der Fall, wenn der Request-Parameter csrftoken mit dem in der Session gespeicherten Token übereinstimmt. Im Fehlerfall wird die globale ActionMessage invalidCSRFToken gesetzt. Die Formular-Actions werden dann nicht ausgeführt. Der Request wird auf die im Formular konfigurierte Fehlerseite weitergeleitet.

Cache-Problematik:

CSRF-geschützte Formulare können grundsätzlich nicht statisch (z.B. vom OSCache) gecached werden. Daher empfiehlt es sich, diese nie auf der Startseite eines Webauftritts oder eines Bereiches einzubinden.

Erweiterter Spamschutz mit Datenbank-Tokens

Die ValidateTimedTokenAction ist eine Formular-Action, mit der die Gültigkeitsdauer von Datenbank-CSRF-Tokens (HFForm.csrfProtection=3) geprüft werden kann.

Standardmäßig überprüft das Formular-Framework die übergebenen CSRF-Tokens (egal welchen Typs) lediglich darauf, ob sie valide sind. Da die Datenbank-Tokens aber auch mit einem Erstellungs-Zeitpunkt versehen sind, kann dieser anschließend mit Hilfe der ValidateTimedTokenAction geprüft werden. Zu diesem Zweck wird das Token (ein Objekt der Klasse BkcmsCsrfToken) im Request-Attribut CmsActionForm_csrfToken bereitgestellt.

Die Action kennt die folgenden Properties:

Name	Funktion
minSeconds	Wenn seit Erstellung des Tokens nicht mindestens die hier angegebene Anzahl Sekunden vergangen ist, wird je nach Konfiguration entweder der Fehlercode tokenTooNew oder das Request-Attribut ValidateTimedTokenAction_TokenError mit dem Integer-Wert 2 gesetzt. Das Attribut kann von nachfolgenden Actions ausgewertet werden. Das geschieht beispielsweise beim Anlegen von Gästebuch-Einträgen, um zu schnell angelegte Einträge als möglichen Spam zu klassifizieren.
maxSeconds	Wenn seit Erstellung des Tokens mehr als die hier angegebene Anzahl Sekunden vergangen ist, wird je nach Konfiguration entweder der Fehlercode tokenTooOld oder das Request-Attribut ValidateTimedTokenAction_TokenError mit dem Integer-Wert 1 gesetzt. Das Attribut kann von nachfolgenden Actions ausgewertet werden.
ignoreErrors	Standardmäßig bricht die Formularbearbeitung ab, wenn das Token ungültig ist. Es wird ein Fehlercode gesetzt und die konfigurierte Fehlerseite angezeigt. Wenn dagegen hier der Wert true angegeben wird, wird die Formularbearbeitung fortgesetzt und anstelle des Fehlercodes nur das Request-Attribut ValidateTimedTokenAction_TokenError gesetzt, auf das nachfolgende Actions reagieren können. Der Wert des Attributs ist vom Typ Integer (0=nicht gefunden, 1=zu alt, 2=zu neu). Wenn ignoreErrors den Wert true hat, wird das unter errorForward konfigurierte Forward mit dem Default "failure" verwendet. Wenn ignoreErrors den Wert false hat oder nicht definiert ist, wird das unter errorForward konfigurierte Forward mit dem Default "next" verwendet. Wenn man dort "success" einträgt, wird auf die Erfolgsseite weitergeleitet, ohne dass weitere Actions ausgeführt werden.
errorForward	Hier kann das alternative Action-Forward konfiguriert werden, das im Fehlerfall verwendet werden soll. Wenn diese Property nicht definiert ist, ist der Defaultwert abhängig vom Wert der Property ignoreErrors entweder "failure" oder "next".

nach oben