Filtrage des requêtes et réécriture d’URL IIS 7.0
par Ruslan Yakushev
IIS 7.0 et ses versions ultérieures incluent un module de filtrage des requêtes basé sur le filtre ISAPI URLScan pour IIS 6.0. Le module vous aide à renforcer la sécurité de vos serveurs web.
L’équipe IIS a également publié un module complémentaire de réécriture d’URL pour IIS, qui fournit des fonctionnalités pour la manipulation d’URL basée sur des règles. Même si l’objectif principal du module de réécriture d’URL consiste à réécrire des chemins d’URL pour les requêtes, le module de réécriture peut également être utilisé comme outil d’application de la sécurité, qui permet d’empêcher l’accès au contenu du site web.
Cet article explique les différences entre ces deux modules et permet de savoir lequel choisir pour renforcer la sécurité de votre serveur web.
Filtrage des requêtes et réécriture d’URL dans le pipeline de traitement des requêtes IIS
Tout d’abord, il est important de comprendre comment le module de filtrage des requêtes et le module de réécriture se connectent au pipeline IIS. Le diagramme suivant montre l’ordre relatif de ces deux modules :
Le module de filtrage des requêtes s’exécute au début du pipeline de traitement des requêtes en gérant l’évènement BeginRequest. Le module évalue les métadonnées de la requête, comme les en-têtes, la chaîne de la requête, la longueur du contenu, etc. afin de déterminer si les métadonnées de la requête correspondent à un filtre existant. S’il existe une correspondance, le module génère une réponse 404 (Fichier introuvable), puis raccourcit le reste du pipeline IIS.
Si le module de filtrage des requêtes n’a pas filtré la requête, celle-ci est transmise au module suivant dans le pipeline IIS, qui peut être le module de réécriture d’URL. Le module de réécriture d’URL évalue la requête par rapport aux règles de réécriture. Si une règle génère une redirection, ou envoie une réponse personnalisée ou abandonne la requête, le module de réécriture génère une réponse appropriée, puis raccourcit le reste du pipeline IIS.
Notez que le module de filtrage des requêtes est placé avant le module de réécriture d’URL. Cela est dû au fait que dans l’architecture IIS, le module de filtrage des requêtes est considéré comme un composant d’opérateur de contrôle d'appels qui protège le serveur web contre les requêtes malveillantes. Le module de réécriture d’URL est considéré comme un composant de manipulation d’URL basé sur serveur, qui fonctionne sur les URL qui ont déjà été filtrées par le module de filtrage des requêtes. Vous pouvez considérer la réécriture d’URL comme logique d’application basée serveur, similaire aux applications ASP.NET, qui peuvent également effectuer une réécriture ou une redirection. Le filtrage des requêtes est une première ligne de défense, tandis que la réécriture d’URL peut être une deuxième barrière de sécurité, plus spécifique à l’application. Pour plus d’informations, consultez le billet de blog « Interaction entre la réécriture d’URL et les modules de filtrage des requêtes pour IIS7 » sur le site web IIS.
Différences entre le filtrage des requêtes et la réécriture d’URL
Les différences conceptuelles entre le filtrage des requêtes et la réécriture d’URL sont les suivantes :
- Le filtrage des requêtes est conçu et optimisé uniquement pour les scénarios de sécurité.
- La réécriture d’URL peut être appliquée à un large ensemble de scénarios, les scénarios de sécurité n’étant qu’un sous-ensemble de ces scénarios.
Dans cet esprit, vous pouvez comparer les fonctionnalités de chaque module qui peuvent être utilisées pour les scénarios de sécurité. Vous devez prendre en compte les catégories suivantes :
- Critères de filtrage. Quel type d’entrée peut être utilisé pour prendre une décision sur le blocage d’une requête ? En outre, quelles conditions peuvent être utilisées pour exprimer la logique de blocage des requêtes ?
- Actions de blocage des requêtes. Quelles actions peuvent être effectuées lorsqu’une requête répond aux critères de filtrage ?
- Impact sur le niveau de performance. Comment le filtrage des requêtes et la réécriture d’URL peuvent-ils affecter le niveau de performance de votre serveur web ?
Critères de filtrage
Le tableau suivant répertorie les critères de filtrage possibles et explique comment chaque module les prend en charge.
| Critère | Pris en charge par le module de filtrage des requêtes ? | Pris en charge par le module de réécriture d’URL ? |
|---|---|---|
| Analyser le chemin de l’URL demandée | Oui, à l’aide de la recherche de substring | Oui, en utilisant des modèles d’expression régulière et de caractère générique |
| Vérifier la longueur de l’URL | Oui | Non |
| Analyser la chaîne de requête | Non | Oui, en utilisant des modèles d’expression régulière et de caractère générique |
| Vérifier la longueur de la chaîne de requête | Oui | Non |
| Vérifier les verbes HTTP | Oui | Oui |
| Vérifier la longueur du contenu de la requête | Oui | Non |
| Analyser les en-têtes HTTP | Non | Oui, en utilisant des modèles d’expression régulière et de caractère générique |
| Vérifier la longueur des en-têtes HTTP | Oui | Non |
| Analyser les variables de serveur | Non | Oui |
| Vérifier l’adresse IP ou le nom d’hôte de l’expéditeur | Non* | Oui |
* Le module de restriction d’IP dans IIS peut être utilisé pour bloquer les requêtes provenant d’adresses IP et de noms d’hôtes spécifiques.
Actions de blocage des requêtes
Le module de filtrage des requêtes n’a qu’une seule action, qu’il effectue lorsqu’une requête correspond à un critère de filtrage. L’action consiste à retourner le code d’état 404 (Fichier introuvable).
Le module de réécriture d’URL fournit un ensemble beaucoup plus large d’options de blocage d’une requête, y compris les éléments suivants :
- L’URL demandée peut être réécrite en une autre URL. Par exemple, pour empêcher la liaison d’images à chaud, vous pouvez réécrire une URL dans un fichier image d’espace réservé pour toutes les requêtes provenant d’un domaine tiers.
- Le client web peut être redirigé vers une autre URL.
- Un code d’état HTTP de votre choix peut être envoyé au client web. Par exemple, vous pouvez envoyer une réponse d’état 401 (Non autorisé) pour les requêtes qui correspondent à des critères de filtrage spécifiques.
- La requête HTTP peut être abandonnée en supprimant la connexion au socket. De cette façon, le client web n’obtient strictement aucune information sur le serveur web.
Impact sur les performances
Les deux modules ont été implémentés pour avoir le moins d’impact possible sur le niveau de performance du serveur web IIS. Toutefois, il existe des différences de niveau de performance importantes entre ces modules :
- Le module de réécriture d’URL s’appuie fortement sur les modèles d’expression régulière. L’évaluation des expressions régulières est une opération consommatrice de ressources et, si vous définissez de nombreuses règles de réécriture complexes, vous pourriez constater un impact notable sur le débit de votre serveur web.
- Le module de filtrage des requêtes n’utilise pas les expressions régulières ni aucun autre critères spéciaux. Il effectue simplement une recherche de substring, ce qui peut avoir un impact beaucoup plus faible sur le débit du serveur web.
Choisir entre le filtrage des requêtes et la réécriture d’URL
Si vous devez choisir entre le filtrage des requêtes et la réécriture d’URL pour renforcer la sécurité de votre serveur web, la règle générale consiste à commencer par le filtrage des requêtes. Le filtrage des requêtes est optimisé pour les scénarios de sécurité et son jeu de fonctionnalités sera probablement suffisant pour implémenter vos exigences de sécurité. Si une de vos exigence ne peut pas être traitée par le module de filtrage des requêtes, utilisez le module de réécriture d’URL pour implémenter cette exigence, et laissez le reste des tâches de sécurité au module de filtrage des requêtes. De cette façon, vous réduisez l’impact sur le niveau de performance du module de réécriture d’URL en ayant la quantité minimale de règles de réécriture à traiter par le serveur.