août
2011
Un article de Philippe Vialatte
Dans la foulée des posts précédents, et au vu de certaines réactions autour de moi, je démarre avec ce post une petite série sur le Web.config, avec comme objectif d’améliorer la sécurité des sites et de lister les bonnes pratiques liées a ce fichier de configuration.
Aujourd’hui, premier billet, on va parler des deux « erreurs » les plus classiques du genre, à savoir l’activation du debug en production, et l’affichage des erreurs.
Symptômes
Lors d’une erreur sur le site, l’utilisateur voit l’écran suivant s’afficher
Ouch.
Raisons
Lorsque l’on va lancer l’application depuis Visual Studio la toute première fois, on va avoir ce petit dialogue (si, tout le monde l’a vu…et cliqué sur OK direct).
Si on laisse l’option par défaut, Visual Studio va automatiquement ajouter, dans le Web.config, la ligne
<compilation debug="true">
L’affichage du message, lui, vient de la propriété CustomErrors, qui est, la plupart du temps, mise a Off dans les environnements de Validation ou de QA, de façon a pouvoir voir le détail des erreurs:
<customErrors mode="Off">
Risques et inconvénients
En fonction de l’endroit ou se produit l’erreur, ce scénario va d’afficher des données permettant de faciliter une attaque. Rien qu’avec l’écran ci-dessus, je sais quelle est la version du Framework, quelle est la version d’ASP.NET.
Je peux aussi déduire d’autres informations a partir du type de l’exception, et la pile des appels me donne une vue sur la logique de développement de l’application (signature des méthodes).
Dans le pire des cas, un éventuel attaquant pourra voir des portions de code (comme ci-dessus).
De plus, lorsque l’application est en mode debug, elle subit des surcouts en terme de performance, liés à:
- La désactivation de certaines optimisations lors de la compilation des pages ASP.NET
- Une augmentation de l’utilisation de la mémoire
- La désactivation du cache pour les Scripts et les images récupérés depuis le handler WebResources.axd
Solution
Pour corriger ces deux problèmes, la solution est simplissime, il suffit de modifier le Web.Config de la façon suivante:
<configuration>
<system.web>
<customErrors mode="RemoteOnly">
<compilation debug="false">
Pour la section customErrors, il est même conseillé de définir des pages d’erreur en fonction du code d’erreur retourné (l’exemple se trouve dans le web.config par défaut 
)
Encore mieux, pour la partie debug, il est possible de « forcer » debug à false sur toutes les applications de la machine en ajoutant, dans le machine.config, la ligne suivante:
<configuration>
<system.web>
<deployment retail="true"/>
Et oui, dans des audits, c’est malheureusement ce qui revient le plus souvent…
Et-ce que ces informations vous sont utiles (je m’adresse a mon unique visiteur, mais je le vouvoies par politesse 
), ou est-ce qu’il vaut mieux que je parle d’autre chose ?
Articles récents
Archives
- janvier 2014
- septembre 2013
- août 2013
- mai 2013
- avril 2013
- janvier 2013
- août 2012
- juin 2012
- mai 2012
- avril 2012
- mars 2012
- novembre 2011
- septembre 2011
- août 2011
- juillet 2011
- juin 2011
- mai 2011
- avril 2011
- février 2011
- janvier 2011
- novembre 2010
- octobre 2010
- septembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009