Fonctions de sécurité d'IIS

Content-Security-Policy (CSP) est une stratégie de sécurité standard utilisée par les navigateurs modernes pour se protéger contre les attaques par injection de données, comme le cross-site scripting (XSS). Les principes du mode de fonctionnement du CSP sont les suivants : utiliser une liste blanche pour déterminer quelles ressources peuvent être chargées en toute sécurité, ignorer les ressources provenant de sources non vérifiées et recueillir des données sur les tentatives de contournement de la politique de sécurité.

Pour la mise en pratique de cette politique, le serveur doit avoir un en-tête HTTP Content-Security-Policy avec une ou plusieurs directives configurées, chaque directive étant associée à un seul type de ressources spécifique. Les directives constituent une politique de sécurité dans laquelle sont spécifiées les règles qui s'appliquent aux ressources.

Pour configurer un CSP pour votre navigateur Internet, ajoutez le code suivant au fichier Web.config :

<system.webServer>
<httpProtocol>
<customHeaders>
<add name="Content-Security-Policy" value="default-src https: data: 'unsafe-inline' 'unsafe-eval'" />
</customHeaders>
</httpProtocol>
</system.webServer>

Remarque : Si vous utilisez les fonctions d'intégration de systèmes tiers d'ABBYY FlexiCapture et l'accès à d'autres hôtes vous est nécessaire, spécifiez-les également dans le fichier Web.config. Après avoir apporté des modifications à vos paramètres de sécurité, vérifiez toujours que le logiciel est resté opérationnel.

Pour plus d'informations sur Content-Security-Policy, consultez ce site Web.

Le HTTP Strict-Transport-Security (HSTS) est un mécanisme de protection des sites Web qui limite toutes les interactions entre le navigateur et le site Web à une connexion sécurisée utilisant le protocole SSL. Un serveur Web sur lequel le HSTS est installé contient une instruction pour que le navigateur utilise exclusivement le HTTPS et lui interdit d'utiliser le HTTP. Le HSTS est principalement utilisé pour repousser les attaques d'interception impliquant des requêtes et des réponses, par exemple les attaques MITM (Man-In-The-Middle).

Pour pouvoir utiliser cette politique de sécurité, vous devez utiliser les règles de réécriture des adresses URL pour ajouter un en-tête Strict-Transport-Security (STS) aux réponses HTTP. Cela est nécessaire pour éviter les requêtes HTTP non souhaitées et rediriger tout le trafic HTTP vers le HTTPS (selon la logique définie dans les règles). Pour mettre en place les règles, vous devez installer le module de réécriture d'URL. Pour plus d'informations, veuillez consulter le site Web de Microsoft.

Pour configurer le STEH pour votre navigateur, ajoutez le code suivant dans votre fichier web.config :

<rule name="Add the STS header in HTTPS responses">
<match serverVariable="RESPONSE_Strict_Transport_Security" pattern=".*" />
<conditions>
<add input="{HTTPS}" pattern="on" />
</conditions>
<action type="Rewrite" value="max-age=31536000" />
</rule>

Remarque : La directive max-age précise la période (en secondes) pendant laquelle la règle sera appliquée. La valeur indiquée dans l'extrait de code ci-dessus équivaut à une période d'un an.

Pour plus d'informations sur le HSTS, veuillez consulter le site Web de Microsoft.

Outre les en-têtes HTTP qui sont essentiels pour améliorer la sécurité de votre serveur Web, il existe également des en-têtes optionnelles. Souvent, ces en-têtes optionnels ne sont régis par aucune norme et leur utilisation augmente le volume de trafic généré par chaque requête HTTP, ce qui facilite la réalisation d'attaques malveillantes.

Voici deux de ces en-têtes optionnels :

• X-Powered-By est un en-tête HTTP qui contient des informations sur les différentes technologies utilisées par le serveur Web.
• X-AspNet-Version est un en-tête HTTP qui contient des informations sur la version ASP.NET utilisée pour déployer des applications sur le serveur Web.

Par défaut, les versions X-Powered-By et X-AspNet sont toutes deux incluses dans les réponses des serveurs. Nous vous recommandons de désactiver ces en-têtes, car le fait de fournir des informations d'identification peut constituer une menace pour la sécurité.

Pour supprimer l'en-tête X-Powered-By de la configuration IIS, collez le code suivant dans votre fichier web.config :

<httpProtocol>
<customHeaders>
<remove name="X-Powered-By" />  
</customHeaders></httpProtocol>

Pour supprimer l'en-tête X-AspNet-Version de votre configuration IIS, collez le code suivant dans votre fichier web.config :

<httpRuntime enableVersionHeader="false" />

X-XSS-Protection est un en-tête HTTP utilisé par les navigateurs pour prévenir les attaques de type Cross-Site Scripting. L'en-tête fonctionne en activant un filtre XSS, qui intercepte les tentatives non désirées d'insertion de code tiers malveillant dans les pages Web ouvertes sur un navigateur.

X-XSS-Protection est compatible avec les navigateurs suivants : Internet Explorer 8+, Chrome et Safari. Cependant, la plupart des navigateurs modernes utilisent une politique de sécurité plus stricte (par exemple, Content-Security-Policy), ce qui rend cet en-tête nécessaire uniquement si vous utilisez un navigateur plus ancien qui ne prend pas en charge CSP.

Pour activer l'en-tête X-XSS-Protection pour votre navigateur, copiez le code suivant dans votre fichier web.config :

<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-XSS-Protection" value="1; mode=block" />
</customHeaders>
</httpProtocol>
</system.webServer>

X-Content-Type-Options est un en-tête HTTP utilisé par les navigateurs pour prévenir les attaques qui exploitent les vulnérabilités MIME (Multipurpose Internet Mail Extensions). MIME est une norme Internet pour les contenus qui sont envoyés via une connexion Internet. Tous les fichiers servis par le serveur Web sont traités par les navigateurs d'une manière qui dépend du type MIME de ces fichiers particuliers. Les navigateurs déterminent le type de ressource soit en utilisant la réponse Content-Type, soit en inspectant le contenu de la ressource, ce qui permet aux attaquants de masquer les fichiers HTML comme des fichiers d'un type différent.

La seule directive disponible pour cet en-tête est la directive nosniff. Elle indique aux navigateurs de n'utiliser que le type MIME spécifié par le serveur Web.

Pour activer l'en-tête X-Content-Type-Options pour votre navigateur, collez le code suivant dans votre fichier web.config :

<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff" />
</customHeaders>
</httpProtocol>
</system.webServer>

L'en-tête du serveur est un en-tête de réponse qui contient des informations sur l'application utilisée par le serveur source pour traiter une requête (par exemple, le numéro de version de l'application). La mise à disposition potentielle de ce type d'informations à des tiers constitue une menace pour la sécurité. Pour cette raison, nous recommandons de supprimer le contenu de l'en-tête du serveur.

Pour supprimer le contenu de l'en-tête du serveur, ajoutez le code suivant dans votre fichier web.config :

<rewrite>  
    <outboundRules rewriteBeforeCache="true">
   <rule name="Remove Server header">
     <match serverVariable="RESPONSE_Server" pattern=".+" />
     <action type="Rewrite" value="" />
   </rule>  
</outboundRules>
</rewrite>

Si vous utilisez IIS 10.0, Windows Server 2016 ou versions ultérieures, utilisez le code suivant à la place :

Set-WebConfigurationProperty  
-pspath 'MACHINE/WEBROOT/APPHOST'  
-filter "system.webServer/security/requestFiltering"  
-name "removeServerHeader"  
-value "True"

Remarque : Les paramètres décrits ci-dessus nécessitent l'installation du module URL Rewrite. Pour plus d'informations, veuillez consulter ladocumentation Microsoft.

Par défaut, il est autorisé d'intégrer les stations Web ABBYY FlexiCapture via iFrame dans les sites Web d'autres entreprises. Cependant, si vous avec connaissance de « frame sniffing », vous pouvez faire ce qui suit afin d'empêcher que le contenu soit hébergé sur un iFrame inter-domaines :

1. Dans le volet Connexions sur le côté gauche, développez le dossier Sites et sélectionnez le site que vous souhaitez protéger.
2. Double-cliquez sur l'icône En-têtes de réponse HTTP dans la liste des fonctionnalités au milieu.
3. Dans le volet Actions sur le côté droit, cliquez sur Ajouter.
4. Dans la boîte de dialogue qui s'ouvre, tapez X-Frame-Options dans le champ Nom et tapez SAMEORIGIN ou DENY dans le champ Valeur.

Pour plus d'informations, veuillez consulter la documentation Microsoft.

La vulnérabilité HTTP POST lente est une variation d'une attaque HTTP lente par déni de service (DoS), autrement appelée attaque HTTP Slowloris. Dans une attaque POST HTTP lente, l'agresseur déclare une grande quantité de données à envoyer dans une requête POST HTTP, puis l'envoie très lentement. Pour réduire la vulnérabilité à une attaque POST HTTP lente du côté du client, il est nécessaire de configurer les limites Web dans les configurations IIS sur les machines où le serveur d'application est installé. Les limites doivent être fixées pour les paramètres suivants :

• ConnectionTimeout
• MinFileBytesPerSec.

Pour plus d'informations sur Limites Web, veuillez consulter la documentation Microsoft.

Le protocole HTTP ne dispose pas de mécanismes de sécurité pour chiffrer les données, tandis que HTTPS fournit un certificat numérique SSL ou TLS permettant de sécuriser la communication entre le serveur et le client. Veuillez vous assurer que tout le trafic entre le navigateur de l'utilisateur et le serveur Web est forcé sur un canal crypté à l'aide de HTTPS. HTTP fonctionne sur le port 80 par défaut. Fermez ce port pour empêcher l'utilisation de HTTP.

TLSv1.1 est considéré comme un protocole de cryptage faible. Un attaquant peut exploiter les faiblesses du protocole pour lire des communications sécurisées ou modifier des messages par malveillance. Nous vous recommandons de toujours utiliser la dernière version possible de TLS et uniquement des chiffrements forts (une liste de chiffrements appropriés peut être trouvée sur https://wiki.mozilla.org/Security/Server_Side_TLS). Pour configurer le chiffrement SSL via la stratégie de groupe :

1. À l'invite de commande, entrez gpedit.msc. L'Éditeur d'objets de stratégie de groupe apparaît.
2. Développez Configuration de l'ordinateur, Modèles d'administration, Réseau, puis cliquez sur Paramètres de configuration SSL.
3. Sous Paramètres de configuration SSL, cliquez sur le paramètre Commande de la suite de chiffrement SSL.
4. Dans le volet Commande de la suite de chiffrement SSL, faites défiler vers le bas du volet.
5. Suivez les instructions intitulées Comment modifier ce paramètre.

Vous devrez redémarrer l'ordinateur pour que les modifications prennent effet.

Les attaques par déni de service distribué (DDoS) consistent à surcharger une application avec des requêtes HTTP, ce qui entraîne une augmentation significative du trafic et rend l'application inaccessible aux utilisateurs légitimes. Il n'est pas toujours aisé de détecter ces attaques, car il est souvent difficile de distinguer le trafic légitime du trafic malveillant.

Pour protéger votre serveur Web contre les attaques DDoS, nous vous recommandons de configurer votre serveur IIS de manière à bloquer l'accès à votre demande si quelqu'un dépasse soit le nombre de demandes autorisées pendant une certaine période, soit le nombre de demandes simultanées autorisées.

Pour mettre en place la protection contre les DDoS dans les SII comme décrit ci-dessus, procédez comme suit :

1. Lancez IIS Manager.
2. Sélectionnez votre site Web dans l'arborescence et double-cliquez sur l'icône Adresse IP et restrictions de domaine sur la page d'accueil du site.
3. Dans le volet Actions, cliquez sur les paramètres Modifier la restriction dynamique.
4. Dans la boîte de dialogue qui s'ouvre, sélectionnez la méthode préférée : Refuser l'adresse IP en fonction du nombre de demandes simultanées ou Refuser l'adresse IP en fonction du nombre de demandes sur une période de temps.
5. Cliquez sur OK.

Dans les paramètres du serveur IIS, vous pouvez également restreindre l'accès à votre application à partir d'adresses IP spécifiques et spécifier le type d'action que le serveur doit effectuer lorsque des tentatives sont faites pour accéder à votre application à partir d'adresses IP restreintes :

1. Lancez IIS Manager.
2. Sélectionnez votre site Web dans l'arborescence et double-cliquez sur l'icône Adresse IP et restrictions de domaine sur la page d'accueil du site.
3. Dans le volet Actions, cliquez sur Modifier les paramètres de restriction dynamique.
4. Dans la boîte de dialogue qui s'ouvre, sélectionnez le type d'action souhaité dans la liste déroulante Type d'action de refus.
5. Cliquez sur OK.

Pour les cas où plusieurs demandes HTTP sont envoyées par plusieurs utilisateurs à partir d'une seule adresse IP, activez le mode proxy dans les paramètres du serveur IIS. Ainsi, le serveur proxy pourra transmettre l'en-tête x-forwarded-for au serveur Web pour aider à identifier l'utilisateur.

Pour activer le mode proxy, procédez comme suit :

1. Lancez IIS Manager.
2. Sélectionnez votre site Web dans l'arborescence et double-cliquez sur l'icône Adresse IP et restrictions de domaine sur la page d'accueil du site.
3. Dans le volet Actions, cliquez sur Modifier les paramètres de fonctionnalité.
4. Dans la boîte de dialogue Modifier les paramètres de restriction d'IP et de domaine, sélectionnez Activer le mode Proxy.
5. Cliquez sur OK.

Pour plus d'informations sur l'utilisation d'IIS pour limiter l'accès à votre application à partir de certaines adresses IP, veuillez consulter la documentation de Microsoft.

Remarque : L'utilisation du mode proxy pour traiter de grandes quantités de trafic peut affecter les performances du système et rendre l'accès à votre application plus difficile pour les utilisateurs légitimes.