Situation in ASP.net vor Version 4

Bereits in ASP.net 1.1 gibt es die sogenannte Request Validation. Dieses System sorgt dafür, dass HTML-Code der innerhalb eines Seitenaufrufs übertragen wird, keinen Schaden anrichten kann. Wenn jemand etwa in ein Kontaktformular Script-Tags und Javascript Anweisungen einfügt, führt dies zu einer Fehlermeldung. Das ist allemal besser, als wenn der Schadcode ausgeführt würde. Weitere Hintergründe kann man in einem Artikel mit dem Titel Request Validation – Preventing Script Attacks nachlesen.

Wenn man weiß, was man tut, kann man die Requestvalidierung auch für sein Projekt deaktivieren. Dazu muss man lediglich in der Web.config das Attribut validateRequest ergänzen und dessen Wert auf “false” setzen:

<configuration>
   <system.web>
      <pages validateRequest="false" />
   </system.web>
</configuration>

Dies ist nötig, wenn man ganz bewusst HTML-Code übertragen will; in einem CMS zum Beispiel.

Neuerungen durch ASP.net 4.0

Das System, wie es bis hierher dargestellt wurde, gilt nur für ASP.net Seiten, also Dateien mit der Endung “aspx”. Andere Komponenten des Frameworks bleiben außen vor und müssen vom Entwickler manuell abgesichert werden.

Seit Version 4.0 des Frameworks ist dies anders. Daher muss man bei der Migration älterer Applikationen ein wenig aufpassen und die Konfiguration passend ergänzen. Wenn man die Meldung “potentially dangerous Request. Form value was detected” erhält, reichte es unter Umständen nicht aus, wie oben die Validierung zu deaktivieren. Diese Einstellung gilt nämlich weiterhin nur für die Seiten. Es bleibt nur die Neuerungen auszuhebeln und das ursprüngliche Verhalten wiederherzustellen. Glücklicherweise reicht auch hierfür ein einzelnes Attribut namens requestValidationMode in der Web.config. Der Wert “2.0” erzwingt das gewohnte Verhalten der zweiten Version von ASP.net:

<configuration>
   <system.web>
      <httpRuntime requestValidationMode="2.0" />
   </system.web>
</configuration>

Diese und weitere Änderungen in der Version 4.0 findet man ebenfalls auf www.ASP.net in einem Artikel namens ASP.NET 4 Breaking Changes