ASP.NET 4.0 - ValidateRequest Verhalten

Es gibt im .NET 4.0 kleine Detailverbesserungen, die auch interessante Side-Effekte zur Folge haben. Einer dieser Effekte betrifft das Attribut ValidateRequest für Webformulare, das entweder in der web.config bzw. in der Page-Direktive auf den Wert "false" gesetzt werden kann. Im Framework bis .NET 3.5 SP1 wird damit die Prüfung auf gefährlichen Code abgeschaltet. In der Regel sollte das auch nur gemacht werden, wenn die Entwickler wirklich wissen, wie sie sich vor schadhaftem Code schützen können, anderseits bedeutet die Deaktivierung mehr Fluch als Segen. Neu wird die Überprüfung viel früher in der Request Pipeline ausgeführt, um ein verbessertes Sicherheitsverhalten zu gewährleisten. Der Nachteil: Das ValidateRequest-Attribut arbeitet auf Page - Level - Ebene und die Prüfung lässt sich im Standardverhalten nicht mehr deaktivieren.

: Abbildung 1: Codeausschnitt mit ValidateRequest="false" in der Direktive

Bei Eingabe eines HTML-Tags wird die Verarbeitung trotz ValidateRequest="false" abgebrochen.

: Abbildung 2: ASP.NET-Fehlermeldung trotz Deaktivierung von ValidateRequest

Damit in ASP.NET 4.0 das vorherige Verhalten erzwungen werden kann, gibt es das Attribut requestValidationMode="2.0" in der httpRuntime-Konfiguration. Das setzen dieser Eigenschaft erfolgt in der web.config. Das Schöne an der Fehlermeldung in Abbildung 2, ich muss nicht lange nach dem Fehler suchen, da in der Beschreibung der Lösungsweg beschrieben ist.

: Abbildung 3: Gewünschte Ausgabe

Warum deaktiviere ich ValidateRequest?

Interessant sind dabei immer die Philosophien, die hier verschiedene Interpretationen zulassen. Eine davon ist die Regel, dass eine Anwendung bei einem Fehler sofort beendet werden soll. Bei der Interaktion mit einem Anwender hat diese Regel jedoch Auswirkung auf die Benutzbarkeit. Hier heisst es wieder die Fehlerbehandlung muss robust sein und der Benutzer muss die Möglichkeit haben, seinen Fehler zu korrigieren. Mit ValidateRequest=“true“ ist diese Empfehlung nicht so einfach umsetzbar.

Was ist das Problem

Im Hintergrund verrichtet auch die Ereignisanzeige sehr gut ihre Arbeit. Treten solche Fehler auf, werden diese auch protokolliert.

: Abbildung 4: Eintrag in der Ereignissanzeige "Anwendung"

Bei Art und Häufigkeit der Fehlermeldungen können Rückschlüsse darüber gezogen werden, ob es sich um einen Eingabefehler oder gezielten Angriffsversuch handelt. Wenn diese Kontrolle deaktiviert wird, ist es empfehlenswert auch den Mehraufwand zu unternehmen, die Validierungsfehler zu protokollieren, damit diese Rückschlüsse weiterhin gezogen werden können.