Verwenden der Anforderungsfilterung

Artikel
03/10/2024

vom IIS-Team

Einführung

UrlScan, ein Sicherheitstool, wurde als Add-On für frühere Versionen der Internetinformationsdienste (Internet Information Services, IIS) bereitgestellt, damit Administratoren strengere Sicherheitsrichtlinien auf ihren Webservern erzwingen können. Innerhalb von IIS 7 und höher wurden alle Kernfunktionen von URLScan in ein Modul namens „Anforderungsfilterung“ (Request Filtering) integriert. Außerdem wurde eine Funktion namens „Ausgeblendete Segmente“ (Hidden Segments) hinzugefügt. In diesem Artikel werden die einzelnen Funktionen der Anforderungsfilterung beschrieben und Beispiele gegeben, wie Sie diese Funktionen in Ihrer Umgebung anwenden können.

Beachten Sie, dass IIS auch ein Modul für die URL-Umschreibung umfasst. Es gibt Unterschiede zwischen diesen beiden Modulen: Die Anforderungsfilterung ist für Sicherheitsszenarien konzipiert und optimiert, während die URL-Umschreibung für eine Vielzahl von Szenarien eingesetzt werden kann (Sicherheitsszenarien sind dabei nur eine Untergruppe dieser Szenarien). Weitere Informationen zu den Unterschieden finden Sie unter IIS 7.0 und höher: Anforderungsfilterung und URL-Umschreibung.

Filtern doppelt codierter Anforderungen

Diese Funktion verhindert Angriffe, die auf doppelt codierten Anforderungen basieren, und wird angewendet, wenn ein Angreifer eine sorgfältig ausgearbeitete doppelt codierte Anforderung an IIS übermittelt. Wenn der Filter für doppelt codierte Anforderungen aktiviert ist, normalisiert IIS die URL zweimal. Wenn sich die erste Normalisierung von der zweiten unterscheidet, wird die Anforderung abgelehnt, und der protokollierte Fehlercode lautet 404.11. Der Filter für doppelt codierte Anforderungen entsprach in UrlScan der Option „VerifyNormalization“.

Wenn Sie nicht möchten, dass IIS die Verarbeitung doppelt codierter Anforderungen zulässt, verwenden Sie Folgendes:

<configuration>
 <system.webServer> 
  <security>
   <requestFiltering
                  allowDoubleEscaping="false">
   </requestFiltering> 
  </security>
 </system.webServer>
</configuration>

Filtern von höchstwertigen Bitzeichen

Diese Funktion lässt alle Anforderungen an IIS zu oder lehnt sie ab, die Nicht-ASCII-Zeichen enthalten, und protokolliert den Fehlercode 404.12. Die Entsprechung in UrlScan lautet „AllowHighBitCharacters“.

Angenommen, Sie möchten höchstwertige Bitzeichen für eine Anwendung, aber nicht für den gesamten Server zulassen. Dann Legen Sie in der Datei „ApplicationHost.config“ allowHighBitCharacters="false" fest; erstellen jedoch innerhalb des Anwendungsstamms eine „Web.config“-Datei, die für diese einzelne Anwendung das Akzeptieren von Nicht-ASCII-Zeichen zulässt. Verwenden Sie in der Datei „Web.config“ Folgendes:

<configuration>
 <system.webServer>
  <security>
   <requestFiltering
                  allowHighBitCharacters="true"
            >
   </requestFiltering>
  </security>
 </system.webServer>
</configuration>

Auf Dateiendungen basierende Filter

Dieses Funktion definiert eine Reihe zulässiger Dateiendungen, die IIS verarbeitet. Wenn IIS eine Anforderung auf der Basis von Dateiendungen ablehnt, wird als Fehlercode 404.7 protokolliert. Die Optionen „AllowExtensions“ und „DenyExtensions“ sind die Entsprechungen für UrlScan.

Nehmen wir an, Sie möchten jeden Dateityp mit Ausnahme von ASP-Dateien zulassen. Dann legen Sie die Option „allowUnlisted“ für „fileExtensions“ auf „true“ fest, und definieren Sie dann einen Eintrag für Dateiendungen, um ASP explizit zu verweigern:

<configuration>
 <system.webServer>
  <security>
   <requestFiltering>
    <fileExtensions allowUnlisted="true" >
     <add fileExtension=".asp" allowed="false"/>
    </fileExtensions>
   </requestFiltering>
  </security>
 </system.webServer>
</configuration>

Auf Anforderungsgrenzwerten basierende Filter

Dieser Filter kombiniert drei Funktionen (die in UrlScan dieselben Namen hatten):

maxAllowedContentLength: oberer Grenzwert für die Inhaltsgröße
maxUrl: obere Grenze für eine URL-Länge
maxQueryString: obere Grenze für die Länge einer Abfragezeichenfolge

Wenn IIS eine Anforderung auf der Basis von Anforderungsgrenzwerten ablehnt, werden die folgenden Fehlercodes 404.7:

413.1, wenn der Inhalt zu groß ist.
404.14, wenn die URL zu lang ist.
404.15, wenn die Abfragezeichenfolge zu lang ist.

Es ist beispielsweise üblich, dass Unternehmen Software kaufen, auf deren Quellcode sie nicht zugreifen können. Im Laufe der Zeit finden sie möglicherweise Sicherheitsrisiken in diesem Code. Es ist häufig nicht einfach, Updates für den betroffenen Code zu erhalten. Die Probleme werden häufig durch eine zu lange URL oder Abfragezeichenfolge oder durch übermäßig viel Inhalt, der an eine Anwendung gesendet wird, verursacht. Nachdem Sie eine sichere Obergrenze ermittelt haben, können Sie Grenzwerte mithilfe der folgenden Konfiguration anwenden, ohne die Binärdateien der Anwendung patchen zu müssen:

<configuration>
 <system.webServer>
  <security>
   <requestFiltering>
    <requestLimits
       maxAllowedContentLength="30000000"
       maxUrl="260"
       maxQueryString="25" 
                  />
   </requestFiltering>
  </security>
 </system.webServer>
</configuration>

Auf Verben basierende Filter

Diese Funktion definiert eine Liste von Verben, die IIS als Teil einer Anforderung akzeptiert. Wenn IIS eine Anforderung auf dieser Basis ablehnt, wird als Fehlercode 404.6 protokolliert. Dies entspricht den Optionen „UseAllowVerbs“, „AllowVerbs“ und „DenyVerbs“ in UrlScan.

Angenommen, Sie möchten nur das Verb „GET“ zulassen. Um dies festzulegen, müssen Sie zuerst die Konfiguration sperren, damit keine Verben zulässig sind, indem Sie die Option allowUnlisted="false" festlegen. Als Nächstes listen Sie die Verben auf, die Sie explizit zulassen möchten, in diesem Fall „GET“.

<configuration>
 <system.webServer>
  <security>
   <requestFiltering>
    <verbs
       allowUnlisted="false"
                  >
     <add verb="GET" allowed="true" />
    </verbs>
   </requestFiltering>
  </security>
 </system.webServer>
</configuration>

Auf URL-Sequenzen basierende Filter

Dieses Feature definiert eine Liste von Sequenzen, die IIS ablehnt, wenn sie Teil einer Anforderung sind. Wenn IIS eine Anforderung für diese Funktion ablehnt, lautet der protokollierte Fehlercode 404.5. Dies entspricht in UrlScan der Funktion „DenyUrlSequences“.

Diese Funktion ist sehr leistungsfähig. Mithilfe des folgenden Codes können Sie verhindern, dass eine bestimmte Zeichensequenz von IIS verarbeitet wird:

<configuration>
 <system.webServer>
  <security>
   <requestFiltering>
    <denyUrlSequences>
     <add sequence=".."/>
    </denyUrlSequences>
   </requestFiltering>
  </security>
 </system.webServer>
</configuration>

Im vorherigen Beispiel wird die Sequenz „..“ abgelehnt. Angenommen, Sie haben eine Anwendung von einem Anbieter erworben, der nicht mehr geschäftlich aktiv ist, und Sie haben festgestellt, dass die Anwendung anfällig war, wenn eine bestimmte Zeichensequenz an sie gesendet wurde. Dann können Sie mithilfe dieser Funktion diese Anwendung schützen, indem Sie einfach diese URL-Sequenz zur Verweigerungsliste hinzufügen, anstatt den Code der Anwendung patchen zu müssen.

Ausgeblendete Segmente herausfiltern

Mithilfe dieser Funktion können Sie definieren, welche Segmente verarbeitet werden können. Wenn IIS eine Anforderung auf dieser Basis ablehnt, wird als Fehlercode 404.8 protokolliert. Dieses Feature ist neu bei IIS 7 und höher und war kein Bestandteil von UrlScan.

Betrachten Sie das folgende Beispiel, in dem zwei URLs auf einem Server vorhanden sind:

http://site.com/bin

http://site.com/binary

Angenommen, Sie möchten Inhalte im Verzeichnis „Binär“, aber nicht im Verzeichnis „Bin“ zulassen. Wenn Sie URL-Sequenzen verwenden und die Sequenz „bin“ ablehnen, verweigern Sie den Zugriff auf beide URLs. Mithilfe der unten gezeigten Konfiguration können Sie den Zugriff auf „bin“ verweigern, eine Bereitstellung in „Binär“ jedoch zulassen:

<configuration>
 <system.webServer>
  <security>
   <requestFiltering>
    <hiddenSegments>
     <add segment="BIN"/>
    </hiddenSegments>
   </requestFiltering>
  </security>
 </system.webServer>
</configuration>

Fehlercodes in IIS 7 und höher

In früheren Versionen könnten Sie UrlScan auf globaler Ebene verwenden, um Sicherheitsrichtlinien zu definieren, die Sie auf Ihren Systemen erzwingen wollten. Mit IIS 7 und höher können Sie diese Richtlinien weiterhin auf globaler Ebene, aber auch pro URL implementieren. Sie können daher alle Vorteile nutzen, die das neue umfangreiche Delegierungsmodell bietet.

Die folgende Tabelle enthält eine Zusammenfassung der Fehlercodes, die IIS protokolliert:

Fehler	Statuscodes
Site nicht gefunden	404,1
Aufgrund von Richtlinie abgelehnt	404,2
Aufgrund von MIME-Zuordnung abgelehnt	404,3
Kein Handler	404,4
Anforderungsfilterung: URL-Sequenz abgelehnt	404,5
Anforderungsfilterung: Verb abgelehnt	404,6
Anforderungsfilterung: Dateiendung abgelehnt	404,7
Anforderungsfilterung: Aufgrund von ausgeblendeten Segmenten abgelehnt	404,8
Verweigert, da das Attribut für ausgeblendete Dateien festgelegt wurde	404,9
Anforderungsfilterung: Abgelehnt, da die URL doppelte Escapezeichen verwendet	404,11
Anforderungsfilterung: Aufgrund von höchstwertigen Bitzeichen abgelehnt	404,12
Anforderungsfilterung: Abgelehnt, da die URL zu lang ist	404,14
Anforderungsfilterung: Abgelehnt, da die Abfragezeichenfolge zu lang ist	404,15
Anforderungsfilterung: Abgelehnt, da die Länge des Inhalts zu groß ist	413.1
Anforderungsfilterung: Abgelehnt, da der Anforderungsheader zu lang ist	431

Freigeben über