Verwenden der Anforderungsfilterung

von IIS-Team

Einführung

UrlScan, ein Sicherheitstool, wurde als Add-On für frühere Versionen von Internetinformationsdienste (IIS) bereitgestellt, sodass Administratoren strengere Sicherheitsrichtlinien auf ihren Webservern erzwingen konnten. Innerhalb von IIS 7 und höher wurden alle Kernfunktionen von URLScan in einem Modul namens "Anforderungsfilterung" integriert, und eine Funktion "Ausgeblendete Segmente" wurde hinzugefügt. In diesem Artikel werden die einzelnen Features der Anforderungsfilterung beschrieben und Beispiele dafür bereitgestellt, wie die Features in Ihrer Umgebung angewendet werden können.

Beachten Sie, dass IIS auch ein Modul für die URL-Umschreibung enthält. Es gibt Unterschiede zwischen diesen beiden Modulen: Die Anforderungsfilterung ist für Sicherheitsszenarien konzipiert und optimiert, während die URL-Neuschreibung für eine vielzahl von Szenarien angewendet werden kann (Sicherheitsszenarien sind nur eine Teilmenge dieser Szenarien). Weitere Informationen zu den Unterschieden finden Sie unter IIS 7.0 und höher Request Filtering and URL Rewriting.

Doppelt kodierte Anforderungen filtern

Dieses Feature verhindert Angriffe, die auf doppelcodierten Anforderungen basieren, und gilt, wenn ein Angreifer eine sorgfältig gestaltete doppelcodierte Anforderung an IIS übermittelt. Wenn der Filter für doppelcodierte 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 ist 404.11. Der Filter für doppelcodierte Anforderungen war die Option "VerifyNormalization" in UrlScan.

Wenn Sie nicht möchten, dass IIS doppelt codierte Anfragen bereitstellt, verwenden Sie Folgendes:

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

Filtern von Zeichen mit hohen Bitwerten

Dieses Feature lässt oder lehnt alle Anforderungen an IIS ab, die Nicht-ASCII-Zeichen enthalten, und protokolliert den Fehlercode 404.12. Die UrlScan-Entsprechung ist AllowHighBitCharacters.

Angenommen, Sie möchten hohe Bitzeichen für eine Anwendung zulassen, aber nicht für den gesamten Server. Legen Sie die allowHighBitCharacters="false" in der ApplicationHost.config-Datei fest; erstellen Sie jedoch innerhalb des Anwendungsstamms eine Web.config Datei, mit der diese einzelne Anwendung Nicht-ASCII-Zeichen akzeptieren kann. Verwenden Sie in der datei Web.config Folgendes:

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

Filter basierend auf Dateierweiterungen

Dieses Feature definiert eine Reihe zulässiger Dateierweiterungen, die IIS bedient. Wenn IIS eine Anforderung basierend auf Dateierweiterungen ablehnt, lautet der protokollierte Fehlercode 404.7. Die Optionen AllowExtensions und DenyExtensions sind die UrlScan-Entsprechungen.

Angenommen, Sie möchten jeden Dateityp mit Ausnahme von ASP-Dateien zulassen. Legen Sie die option allowUnlisted für fileExtensions auf "true" fest, und definieren Sie dann einen Dateierweiterungseintrag, um ASP explizit zu verweigern:

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

Filtern basierend auf Anforderungsgrenzwerten

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

• maxAllowedContentLength–Obergrenze 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 basierend auf Anforderungsgrenzwerten ablehnt, lautet der protokollierte Fehlercode:

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

Beispielsweise ist es sehr üblich, dass Unternehmen Software kaufen, auf die sie keinen Quellcodezugriff haben. Im Laufe der Zeit können sie Sicherheitsrisiken in diesem Code finden. Das Abrufen von Updates für den betroffenen Code ist häufig nicht einfach. Die Probleme werden häufig durch eine zu lange URL oder Abfragezeichenfolge oder durch ein Übermaß an Inhalten verursacht, die an eine Anwendung gesendet werden. Nachdem Sie eine sichere obere Grenze ermittelt haben, können Sie Grenzwerte mithilfe der folgenden Konfiguration anwenden, ohne die Binärdateien der Anwendung zu patchen:

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

Nach Verben filtern

Dieses Feature definiert eine Liste von Verben, die IIS als Teil einer Anforderung akzeptiert. Wenn IIS eine Anforderung basierend auf diesem Feature ablehnen, lautet der protokollierte Fehlercode 404.6. 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>

Filter basierend auf URL-Sequenzen

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

Dies ist ein sehr leistungsfähiges Feature. Mit dem folgenden Code können Sie verhindern, dass eine bestimmte Zeichensequenz von IIS bereitgestellt wird:

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

Im vorherigen Beispiel ist ".." Sequenz wird zurückgewiesen. Angenommen, Sie haben eine Anwendung von einem Anbieter erworben, der aus dem Geschäft gegangen ist, und Sie haben festgestellt, dass die Anwendung anfällig war, wenn eine bestimmte Zeichensequenz an sie gesendet wurde. Mithilfe dieses Features können Sie diese Anwendung schützen, indem Sie einfach diese URL-Sequenz zur Liste "Verweigert" hinzufügen, ohne den Code der Anwendung patchen zu müssen.

Ausgeblendete Segmente herausfiltern

Mit diesem Feature können Sie definieren, welche Segmente "servierbar" sind. Wenn IIS eine Anforderung basierend auf diesem Feature ablehnt, lautet der protokollierte Fehlercode 404.8. Dieses Feature ist neu bei IIS 7 und höher; es war nicht Teil 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 Binärverzeichnis zulassen, aber nicht den Inhalt im Bin-Verzeichnis. 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 das Verzeichnis ‚bin‘ verweigern, aber dennoch den Inhalt in binärer Form bereitstellen lassen.

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

IIS 7 und höher Fehlercodes

In früheren Versionen könnten Sie UrlScan auf globaler Ebene verwenden, um Sicherheitsrichtlinien zu definieren, die Sie auf Ihren Systemen erzwingen möchten. 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 Rich-Delegationsmodell bietet.

Die folgende Tabelle fasst die Fehlercodes aus den IIS-Protokollen zusammen.