Utiliser le filtrage des demandes

Article
03/08/2024

par l’équipe IIS

Introduction

UrlScan, un outil de sécurité, a été fourni en tant que module complémentaire aux versions antérieures d’Internet Information Services (IIS) afin que les administrateurs puissent appliquer des stratégies de sécurité plus strictes sur leurs serveurs web. Dans IIS 7 et versions ultérieures, toutes les principales fonctionnalités d’URLScan ont été incorporées dans un module appelé Filtrage des demandes, et une fonctionnalité Segments masqués a été ajoutée. Cet article décrit chaque fonctionnalité de Filtrage des demandes et fournit des exemples de la façon dont les fonctionnalités peuvent être appliquées dans votre environnement.

Notez que IIS inclut également un module pour la réécriture d’URL. Il existe des différences entre ces deux modules : le Filtrage des demandes est conçu et optimisé pour les scénarios de sécurité, tandis que la réécriture d’URL peut être appliquée pour un large ensemble de scénarios (les scénarios de sécurité ne sont qu’un sous-ensemble de ces scénarios). Pour plus d’informations sur les différences, consultez IIS 7.0 et versions ultérieures du filtrage et de la réécriture d’URL.

Filtrer les requêtes codées en double

Cette fonctionnalité empêche les attaques qui s’appuient sur des requêtes codées à double encodées et s’applique si un attaquant envoie une demande codée doublement soigneusement à IIS. Lorsque le filtrage des demandes double encodé est activé, IIS normalise l’URL deux fois ; si la première normalisation est différente de la seconde, la requête est rejetée et le code d’erreur journalisé est 404.11. Le filtrage des demandes codées deux fois était l’option VerifyNormalization dans UrlScan.

Si vous ne souhaitez pas que IIS autorise le traitement des requêtes encodées doublées, utilisez les éléments suivants :

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

Filtrer les caractères de bits élevés

Cette fonctionnalité autorise ou rejette toutes les requêtes adressées à IIS qui contiennent des caractères non ASCII et enregistre le code d’erreur 404.12. L’équivalent UrlScan est AllowHighBitCharacters.

Par exemple, supposons que vous souhaitez autoriser des caractères de bits élevés pour une application, mais pas pour l’ensemble du serveur. Définissez l’allowHighBitCharacters="false" dans le fichier ApplicationHost.config ; mais dans la racine de l’application, créez un fichier Web.config qui permet à cette application unique d’accepter des caractères non ASCII. Dans le fichier Web.config, utilisez :

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

Filtrer en fonction des extensions de fichier

Cette fonctionnalité définit un ensemble d’extensions de fichier autorisées que IIS sert. Lorsque IIS rejette une demande basée sur des extensions de fichier, le code d’erreur enregistré est 404.7. Les options AllowExtensions et DenyExtensions sont les équivalents UrlScan.

Par exemple, supposons que vous souhaitiez autoriser chaque type de fichier, à l’exception des fichiers ASP. Définissez l’option allowUnlisted pour fileExtensions sur « true », puis définissez une entrée d’extension de fichier pour refuser explicitement ASP :

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

Filtrer en fonction des limites de demande

Ce filtre combine trois fonctionnalités (qui ont les mêmes noms dans UrlScan) :

maxAllowedContentLength – limite supérieure sur la taille de contenu
maxUrl – limite supérieure sur une longueur d’URL
maxQueryString – limite supérieure sur la longueur d’une chaîne de requête

Lorsque IIS rejette une demande en fonction des limites de requête, le code d’erreur enregistré est le suivant :

413.1 si le contenu est trop long.
404.14 si l’URL est trop grande.
404.15 si la chaîne de requête est trop longue.

Par exemple, il est très courant pour les entreprises d’acheter des logiciels auxquels elles n’ont pas accès au code source. Au fil du temps, ils peuvent trouver des vulnérabilités dans ce code. L’obtention de mises à jour pour le code affecté n’est souvent pas facile. Les problèmes sont fréquemment causés par une URL ou une chaîne de requête trop longue ou par un excès de contenu envoyé à une application. Une fois que vous avez déterminé une limite supérieure sécurisée, vous pouvez appliquer des limites à l’aide de la configuration ci-dessous, sans avoir à corriger les fichiers binaires d’application :

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

Filtrer par verbes

Cette fonctionnalité définit une liste de verbes acceptés par IIS dans le cadre d’une demande. Lorsque IIS rejette une demande basée sur cette fonctionnalité, le code d’erreur journalisé est 404.6. Cela correspond aux options UseAllowVerbs, AllowVerbs et DenyVerbs dans UrlScan.

Par exemple, supposons que vous ne souhaitez autoriser que le verbe GET. Pour définir ce paramètre, vous devez d’abord verrouiller la configuration afin qu’aucun verbe ne soit autorisé en définissant l’option allowUnlisted="false". Ensuite, répertoriez les verbes que vous souhaitez autoriser explicitement, dans ce cas, GET.

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

Filtrer en fonction des séquences d’URL

Cette fonctionnalité définit une liste de séquences rejetées par IIS lorsqu’elle fait partie d’une demande. Lorsque IIS rejette une demande pour cette fonctionnalité, le code d’erreur journalisé est 404.5.Cela correspond à la fonctionnalité DenyUrlSequences dans UrlScan.

Il s’agit d’une fonctionnalité très puissante. À l’aide du code suivant, vous pouvez empêcher la prise en charge d’une séquence de caractères donnée par IIS :

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

Dans l’exemple précédent, le « . » la séquence est rejetée. Supposons que vous ayez acheté une application à un fournisseur qui a fait faillite et que vous ayez découvert que l'application était vulnérable lorsqu'une séquence de caractères donnée lui était envoyée. À l’aide de cette fonctionnalité, vous pouvez protéger cette application en ajoutant simplement cette séquence d’URL à la liste refusée sans avoir à corriger le code de l’application.

Filtrer les segments masqués

Cette fonctionnalité vous permet de définir quels segments sont « serviables » Quand IIS rejette une demande conformément à cette fonction, le code d'erreur enregistré est 404.8. Cette fonctionnalité est nouvelle pour IIS 7 et versions ultérieures ; elle ne faisait pas partie de UrlScan.

Prenons l’exemple suivant où il existe deux URL sur un serveur :

http://site.com/bin

http://site.com/binary

Supposons que vous souhaitez autoriser le contenu dans le répertoire binaire, mais pas le contenu du répertoire bin. Si vous utilisez des séquences d’URL et refusez la séquence « bin », vous refusez l’accès aux deux URL. En utilisant la configuration indiquée ci-dessous, vous pouvez refuser l’accès à bin, mais disposer du contenu dans le fichier binaire servi :

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

Codes d’erreur IIS 7 et versions ultérieures

Dans les versions précédentes, vous pouvez utiliser UrlScan à un niveau global pour définir des stratégies de sécurité que vous souhaitez appliquer sur vos systèmes. Avec IIS 7 et versions ultérieures, vous pouvez toujours implémenter ces stratégies au niveau global, mais également par URL. Vous pouvez donc tirer parti de tous les avantages que fournit le nouveau modèle de délégation riche.

Le tableau suivant est un résumé des journaux IIS des codes d’erreur :

Erreur	Codes d’état
Site introuvable	404,1
Refusé par la stratégie	404,2
Refusé par la carte mime	404,3
Aucun gestionnaire	404,4
Filtrage des demandes : séquence d’URL refusée	404,5
Filtrage des demandes : verbe refusé	404,6
Filtrage des demandes : extension de fichier refusée	404,7
Filtrage des demandes : refusé par segment masqué	404,8
Refusé depuis que l’attribut de fichier masqué a été défini	404,9
Filtrage des demandes : refusé, car l’URL a doublé l’échappement	404,11
Filtrage des demandes : refusé en raison de caractères de bits élevés	404,12
Filtrage des demandes : refusé, car l’URL est trop longue	404,14
Filtrage des demandes : refusé, car la chaîne de requête est trop longue	404,15
Filtrage des demandes : refusé, car la longueur du contenu est trop grande	413.1
Filtrage des demandes : refusé, car l’en-tête de requête est trop long	431

Partager via