Liste de contrôle : sécurisation d'ASP.NET

Les décisions relatives à la sécurité ne doivent pas reposer sur des validations côté client ; elles doivent être prises côté serveur.

Le site Web est partitionné en zones d'accès public et en zones restreintes qui requièrent un accès par authentification. Les informations navigant entre ces zones ne doivent pas être des informations d'authentification sensibles.

Les identités utilisées pour accéder aux ressources distantes à partir des applications Web ASP.NET sont clairement identifiées.

Les mécanismes ont été identifiés pour sécuriser les informations d'authentification, les tickets d'authentification et d'autres informations sensibles sur le réseau et dans les magasins persistants.

Une approche sécurisée de la gestion des exceptions est identifiée. L'application s'arrête en toute sécurité en cas d'exceptions.

Le site intègre des contrôles d'autorisation granulaires des pages et des répertoires.

Les contrôles Web, les contrôles utilisateur et le code d'accès aux ressources sont tous partitionnés dans leurs propres assemblys pour une sécurité granulaire.

Les données utilisateur sont validées en fonction du type, de la longueur, du format et de la plage. Les entrées sont contrôlées pour rechercher les données connues valides et sécurisées, puis les données dangereuses et malveillantes.

Les entrées sous forme de chaîne du formulaire sont validées à l'aide d'expressions régulières (par exemple, avec le contrôle RegularExpressionValidator.)

Les contrôles HTML réguliers, les chaînes de requête, les cookies et d'autres formes d'entrée sont validées à l'aide de la classe Regex et/ou de votre code de validation personnalisé.

Le contrôle RequiredFieldValidator est utilisé partout où des données sont entrées.

Les vérifications de plage des contrôles du serveur sont effectuées par les contrôles RangeValidator.

Les entrées de format libre sont désinfectées pour nettoyer les données malveillantes.

Les noms de fichier d'entrée sont bien formés et leur validité est vérifiable dans le contexte de l'application.

Les sorties comprenant des entrées sont codées avec HtmlEncode et UrlEncode.

MapPath restreint le mappage entre applications le cas échéant.

Le codage de caractère est configuré par le serveur (ISO-8859-1 est recommandé).

L'option validateRequest d'ASP.NET version 1.1 est activée.

URLScan est installé sur le serveur Web.

L'option de cookie HttpOnly est utilisée pour la défense en profondeur afin d'éviter les scripts inter-site (s'applique à Internet Explorer 6.1 ou ultérieur).

Les paramètres SQL sont utilisés dans le code d'accès aux données pour valider la longueur et le type des données et pour éviter une injection SQL.

Le site est partitionné en zones restreintes et en zones publiques.

Les URL absolues sont utilisées pour la navigation lorsque le site est partitionné en dossiers sécurisés et non sécurisés.

SSL (Secure Sockets Layer) est utilisé pour protéger les informations d'authentification et les cookies d'authentification.

L'attribut slidingExpiration est configuré sur « false » et des délais d'attente limités sont utilisés pour les cookies d'authentification lorsque les cookies ne sont pas protégés à l'aide de SSL.

Le cookie d'authentification par formulaire est limité aux connexions HTTPS à l'aide de l'attribut requireSSL ou de la propriété de cookie Secure.

Le cookie d'authentification est crypté et l'intégrité est contrôlée (protection="All").

Les cookies d'authentification ne sont pas persistants.

Les cookies d'application ont des combinaisons de nom/chemin d'accès uniques.

Les cookies de personnalisation sont séparés des cookies d'authentification.

Les mots de passe ne sont pas stockés directement dans le magasin d'utilisateurs ; ce sont les résumés avec salt des mots de passe qui sont stockés à la place.

Les informations d'emprunt d'identité (dans le cas de l'utilisation d'une identité fixe) sont cryptées dans le fichier de configuration à l'aide de Aspnet_setreg.exe.

Des stratégies de mot de passe sûr sont implémentées pour l'authentification.

L'élément <credentials>
n'est pas utilisé au sein de l'élément <forms>
pour l'authentification par formulaire (utilisez-le uniquement pour le test).

L'autorisation d'accès à l'URL est utilisée pour le contrôle d'accès à la page et au répertoire.

L'autorisation d'accès au fichier est utilisée avec l'authentification Windows.

Les demandes d'autorisation principales permettent de sécuriser l'accès aux classes et aux membres.

Les contrôles de rôle explicites sont utilisés si une autorisation affinée est requise.

L'extraction du fichier de configuration est bloquée à l'aide de HttpForbiddenHandler.

Le compte le moins privilégié est utilisé pour exécuter ASP.NET.

Les informations d'authentification de compte personnalisé (si elles sont utilisées) sont cryptées sur l'élément <processModel>
à l'aide de Aspnet_setreg.exe.

Pour renforcer la stratégie à l'échelle de l'ordinateur, les paramètres de Web.config sont verrouillés à l'aide de allowOveride="false" dans Machine.config.

SSL est utilisé pour protéger les données sensibles sur le réseau.

Les données sensibles ne sont pas passées à travers les pages ; elles sont maintenues à l'aide de la gestion d'état côté serveur.

Les données sensibles ne sont pas stockées dans des cookies, des champs de formulaire cachés ou des chaînes de requête.

La mise en cache en sortie des pages contenant des données sensibles est désactivée.

Les mots de passe en texte plein sont évités dans les fichiers Web.config et Machine.config (Aspnet_setreg.exe est utilisé pour crypter les informations d'authentification).

Le cookie de session est protégé en utilisant SSL sur toutes les pages requérant un accès authentifié.

Le service d'état de la session est désactivé s'il n'est pas utilisé.

Le service d'état de la session (s'il est utilisé) s'exécute à l'aide du compte le moins privilégié.

L'authentification Windows est utilisée pour la connexion à la base de données d'état de Microsoft® SQL Server?.

L'accès aux données d'état est restreint dans SQL Server.

Les chaînes de connexion sont cryptées à l'aide de Aspnet_setreg.exe.

Le canal de communication vers le magasin d'état est crypté (IPSec ou SSL).

L'affichage de l'état est protégé à l'aide de codes d'authentification de message (MAC).

Les chaînes de requête avec secrets de serveur sont hachées.

Tous les paramètres de saisie sont validés.

Page.ViewStateUserKey est utilisé pour contrer les attaques en un seul clic.

Une gestion des exceptions structurée est utilisée.

Les détails des exceptions sont consignés dans un journal sur le serveur.

Les pages d'erreurs génériques ne contenant pas de messages offensifs sont renvoyées au client.

Des gestionnaires d'erreurs au niveau de la page ou au niveau de l'application sont implémentés.

L'application fait la différence entre les erreurs et les conditions d'exception.

Le processus ASP.NET est configuré pour permettre la création de nouvelles sources d'événements au moment de l'exécution, ou la création de sources d'événements au moment de l'installation.

<trace/>
Le suivi est activé sur les serveurs de production.

<trace enabled="false">

<globalization>
Le codage des demandes et des réponses est configuré de manière appropriée.

<httpRuntime>
maxRequestLength est configuré pour empêcher les utilisateurs de charger de très
gros fichiers (facultatif).

<compilation>
Le débogage des compilations est désactivé sur les serveurs de production en configurant
debug="false"

<compilation debug="false" . . ./>

<pages>
Si l'application n'utilise pas l'affichage de l'état, enableViewState est configuré sur « false ».

<pages enableViewState="false" . . ./>

Si l'application utilise l'affichage de l'état, enableViewState est configuré sur « true » et enableViewStateMac est configuré sur « true » pour détecter la falsification de l'affichage de l'état.

<pages enableViewState="true" enableViewStateMac="true" />

<customErrors>
Les pages d'erreurs personnalisées sont renvoyées au client et les détails des exceptions ne sont pas renvoyés en configurant mode="On".

<customErrors mode="On" />

Une page d'erreurs générique est spécifiée par l'attribut defaultRedirect.

<customErrors mode="On" defaultRedirect="/apperrorpage.htm" />

<authentication>
Le mode d'authentification est configuré de manière appropriée pour prendre en charge les exigences de l'application. Pour renforcer l'utilisation d'un type d'authentification spécifique, l'élément </location>
associé à allowOverride="false" est utilisé.

<location path="" allowOverride="false">  
  <system.web>    
    <authentication mode="Windows" />  
  </system.web></location>

<forms>
Le site Web est partitionné pour l'accès public et l'accès restreint.
La configuration de l'authentification par formulaire est sécurisée :

<forms loginUrl="Restricted\login.aspx"       
  protection="All"       
  requireSSL="true"       
  timeout="10"       
  name="AppNameCookie"       
  path="/FormsAuth"       
  slidingExpiration="true" />

Le cookie d'authentification est crypté et l'intégrité est contrôlée (protection).
SSL est requis pour le cookie d'authentification (requireSSL).
L'expiration décalée est configurée sur false si SSL n'est pas utilisé (slidingExpiration).
La durée de vie de la session est restreinte (timeout).
Les noms et les chemins d'accès aux cookies sont uniques (name et path).
L'élément <credentials>n'est pas utilisé.

<identity>
Les identités d'emprunt (si elles sont utilisées) sont cryptées dans le Registre en utilisant Aspnet_setreg.exe :

<identity impersonate="true"          
   userName="registry:HKLM\SOFTWARE\YourApp\
identity\ASPNET_SETREG,userName"          
   password="registry:HKLM\SOFTWARE\YourApp\
identity\ASPNET_SETREG,password"/>

<authorization>
Le format correct des noms de rôles est vérifié.

<machineKey>
Si plusieurs applications Web ASP.NET sont déployées sur le même serveur Web, le paramètre « IsolateApps » est utilisé pour garantir qu'une clé séparée sera générée pour chaque application Web.

<machineKey validationKey="AutoGenerate,IsolateApps"
   decryptionKey="AutoGenerate,IsolateApps"      
   validation="SHA1" />

Si l'application Web ASP.NET est exécutée dans un parc Web, des clés d'ordinateur spécifiques sont utilisées, et ces clés sont copiées à travers tous les serveurs du parc.
Si l'affichage de l'état est activé, l'attribut validation est configuré sur « SHA1 ».
L'attribut validation est configuré sur « 3DES » lorsque le cookie d'authentification par formulaire doit être crypté pour l'application.

<sessionState>
Si mode="StateServer", alors les informations d'authentification sont stockées dans un formulaire crypté au sein du Registre à l'aide de Aspnet_setreg.exe.
Si mode="SQLServer", alors l'authentification Windows est utilisée pour la connexion à la base de données du magasin d'états et les informations d'authentification sont stockées dans un formulaire crypté au sein du Registre à l'aide de Aspnet_setreg.exe.

<httpHandlers>
Les types de fichier inutilisés sont mappés vers HttpForbiddenHandler pour éviter que les fichiers soient extraits sur HTTP. Par exemple :

<add verb="*" path="*.rem"            
   type="System.Web.HttpForbiddenHandler"/> 

<processModel>
Un compte moins privilégié comme ASPNET est utilisé pour exécuter le processus ASP.NET.

<processModel userName="Machine" password="AutoGenerate"

Le compte système n'est pas utilisé pour exécuter le processus ASP.NET.
Le privilège Agir en tant que partie du système d'exploitation n'est pas accordé au compte du processus.

<processModel  
   userName="registry:HKLM\SOFTWARE\MY_SECURE_APP\  
   processmodel\ASPNET_SETREG,userName"  
   password="registry:HKLM\SOFTWARE\MY_SECURE_APP\  
   processmodel\ASPNET_SETREG,password" . . ./>

Si l'application utilise Enterprise Services, comAuthenticationLevel et comImpersonationLevel sont configurés de manière appropriée.
L'authentification au niveau Call est réglée au minimum pour s'assurer que tous les appels de méthode pourront être authentifiés par l'application distante.
PktPrivacy est utilisé pour crypter les données et les protéger des falsifications à travers le réseau en l'absence d'une sécurité des canaux de l'infrastructure (IPSec).
PktIntegrityest utilisé pour éviter les falsifications sans cryptage (les épieurs peuvent voir vos données avec les moniteurs réseau).

<webServices>
Les protocoles non utilisés sont désactivés.
La génération automatique de WSDL (Web Services Description Language) est désactivée (facultatif).

Etat de la session. Pour éviter l'affinité du serveur, l'état de la session ASP.NET est conservé hors processus dans la base de données d'états ASP.NET SQL Server ou dans le service d'états hors processus qui s'exécute sur un ordinateur distant.

Cryptage et vérification. Les clés utilisées pour crypter et vérifier l'authentification par formulaire.

DPAPI DPAPI ne peut pas être utilisé avec la clé d'ordinateur pour crypter les données courantes auxquelles tous les serveurs du parc doivent accéder. Pour crypter des données partagées sur un serveur distant, utilisez une autre implémentation, telle que 3DES.

Les applications ont des clés d'ordinateur distinctes.
Utilisez IsolateApps sur <machineKey>
ou utilisez les éléments <machineKey>
par application.

<machineKey validationKey="AutoGenerate,IsolateApps"
    decryptionKey="AutoGenerate,IsolateApps" . . . />

Des combinaisons de nom/chemin d'accès uniques aux cookies d'authentification par formulaire sont activées pour chaque application.

Plusieurs processus (pools d'applications IIS 6.0) sont utilisés pour l'isolation d'application sur Microsoft Windows® Server 2003.

Plusieurs comptes utilisateurs anonymes (et emprunts d'identité) sont utilisés pour l'isolation d'application sur Windows 2000.

Des clés d'ordinateur courantes sont activées sur tous les serveurs d'un parc Web.

Des clés d'ordinateurs séparées sont utilisées pour chaque application lorsque plusieurs applications sont hébergées sur un seul serveur.

Des niveaux de confiance de la sécurité d'accès au code sont utilisés pour l'isolation du processus et pour restreindre l'accès aux ressources du système (requiert .NET Framework version 1.1).

Fichiers temporaires ASP.NET

%windir%\Microsoft.NET\Framework\{version}Temporary ASP.NET Files

Compte du processus ASP.NET et emprunts d'identités : Contrôle total

Répertoire temporaire

(%temp%)

Compte du processus ASP.NET : Contrôle total

Répertoire .NET Framework

%windir%\Microsoft.NET\Framework\{version}

Compte du processus ASP.NET et emprunts d'identités :
Lecture et Exécution
Contenu du dossier

Répertoire de configuration de .NET Framework

%windir%\Microsoft.NET\Framework\{version}\CONFIG

Compte du processus ASP.NET et emprunts d'identités :
Lecture et Exécution
Affichage du contenu du dossier
Lecture

Racine du site Web

C:\inetpub\wwwroot

ou le chemin d'accès par défaut vers lequel pointe le site Web
Compte du processus ASP.NET : Contrôle total

Répertoire racine du système

%windir%\system32

Compte du processus ASP.NET : Lecture

Cache de l'assembly global

%windir%\assembly

Compte du processus et emprunts d'identités : Lecture

Répertoire du contenu

C:\inetpub\wwwroot\YourWebApp

Compte du processus :
Lecture et Exécution
Affichage du contenu du dossier
Lecture
Remarque : avec .NET Framework version 1.0, tous les répertoires parents, du répertoire de contenu au répertoire racine du système, requièrent également les autorisations ci-dessus. Les répertoires parents sont les suivants :

C:\
C:\inetpub\
C:\inetpub\wwwroot\

Les autorisations Web IIS sont configurées.
Le répertoire bin ne dispose par d'autorisations de navigation en Lecture, Écriture ou par Répertoire.
Les autorisations d'exécution sont réglées sur None (Aucun).

Les paramètres d'authentification sont supprimés (de sorte que tout accès est refusé).