Accueil > .Net, C#, Développement, Sécurité > [Sécurité] Chiffrer les données de configuration

[Sécurité] Chiffrer les données de configuration

Dans le cadre de mon travail, nous nous penchons actuellement sur la sécurité applicative, autour d’une application Web.
Du coup, je vais (peut être ^^) faire plusieurs billets à ce sujet.

Le premier et présent billet va parler du chiffrement des données de configuration.
Dans le cadre du projet Top Ten de l’OWASP (EN), cet élément est contenu (mais ne fait pas tout, loin de là) dans le point « A5 – Security Misconfiguration ».

 

Qu’est ce que le chiffrement ?

 
Le chiffrement est une technique de cryptographie qui permet, à partir d’une clef, de transformer un message (texte, document, flux…) en quelque chose qui n’est plus « humainement » lisible.
Mais le chiffrement est réversible, ce qui veut dire qu’il est possible de revenir à l’état d’origine.
Si la clef de chiffrement est la même que la clef de déchiffrement, on dit que ce dernier est symétrique.
Dans le cas contraire (utilisation de deux clefs différentes), alors le chiffrement est asymétrique : une clef privée est utilisée pour chiffrer, une clef publique pour déchiffrer. C’est la clef publique qui va être communiquée à toute entité (personne, application…) devant lire le message.

Pour plus d’information, je vous invite à aller voir la page Wikipédia dédiée au chiffrement (FR).

 

Quels sont les fichiers de configuration que l’on peut chiffrer ?

 
Il y a deux possibilités pour deux méthodes très différentes.
Il est possible d’une part de chiffrer le fichier Web.Config des applications Web, en passant par IIS.
Et il est également possible de chiffrer les fichiers de type App.Config en passant par du code .Net.

Cependant, dans les deux cas, il est très important de bien garder une chose à l’esprit : la clef de chiffrement va être conservée sur la machine sur laquelle le chiffrement est effectué.

 

Comment faire pour chiffrer un Web.Config ?

 
Pour le chiffrement des Web.Config, il faut se reporter à l’exécutable aspnet_regiis.exe.
Il y a une section (bas de page) sur la MSDN pour savoir où le trouver : ASP.NET IIS Registration Tool (Aspnet_regiis.exe) (EN).

Il y a également un descriptif de toutes les commandes pour cet exécutable, mais dans notre cas, c’est surtout -pe et -pd qui nous intéresse.

Pour chiffrer un Web.Config, on va donc pouvoir lancer la ligne de commande suivante :

aspnet_regiis.exe -pe "appSettings" -app "WebSite" -prov "RsaProtectedConfigurationProvider"

Le -pe indique qu’il faut chiffrer la section mentionnée (ici, appSettings).
Le -app permet de spécifier le site web et donc par voie de conséquence le fichier Web.Config qui va être chiffré.
Enfin, le -prov indique le provider, c’est à dire l’algorithme de chiffrement.

Il n’y a que deux providers : RsaProtectedConfigurationProvider (EN ; provider par défaut) et DpapiProtectedConfigurationProvider (EN).

Prenons l’exemple du Web.Config de RavenDB :

 <appSettings>
  <add key="Raven/DataDir" value="~\Database\System" />
  <add key="Raven/AnonymousAccess" value="All" />
 </appSettings>

Deviendra :

 <appSettings configProtectionProvider="RsaProtectedConfigurationProvider">
  <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
   xmlns="http://www.w3.org/2001/04/xmlenc#">
   <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc" />
   <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
    <EncryptedKey xmlns="http://www.w3.org/2001/04/xmlenc#">
     <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
     <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
      <KeyName>Rsa Key</KeyName>
     </KeyInfo>
     <CipherData>
    <CipherValue>pE46+3Ur31E3QS5X6RCpAnvC8PlcHX4piR7tOgY4ZnJF7e2lPXElCYhbNzoRbQWR7/L2wdGqNklvEd6xWsMAr/OBKs6WuCz5I/nUdFKTEjUJ/lZVLnr+xoMOyNTW7m6Lz6gfBGl7tL7QkXzeAPuhR+tCRKOYeiDrav1IqgUhWcQ=</CipherValue>
     </CipherData>
    </EncryptedKey>
   </KeyInfo>
   <CipherData>
    <CipherValue>xlkHq2FJY0dEeJNDqy/4RXe4tw48zk13p5vqvyMM5FLp/9g7s7GWiLUBrKOpZlgqrOiQH2SKZg3De1Yvw/EXIRQ9q3qAqQmoMVtL3OMCb/ws7brITEJSxjIbkN61PEfBZyMIuaIlB93Yz8BCJHyHIm46o+xHjdE2ytWPLmv/e2k+TYSKKR671P/77G2j874cc7M5NPfUW8Y=</CipherValue>
   </CipherData>
  </EncryptedData>
 </appSettings>

C’est plus verbeux, mais quand même nettement moins lisible !

Peut-on revenir à l’état initial ?
Oui, avec la ligne de commande suivante :

aspnet_regiis.exe -pd "appSettings" -app "WebSite"

Rien de très compliqué, non ?
Alors regardons côté App.Config.

 

Comment faire pour chiffrer un App.Config ?

 

Là, c’est un peu plus complexe étant donné qu’il faut passer par du code.

Dans un premier temps, il faut utilisé l’assembly System.Configuration et notamment les classes Configuration et ConfigurationManager :

// Attention, "configPath" pointe vers l'exécutable et non le fichier de configuration directement !
Configuration config = ConfigurationManager.OpenExeConfiguration(configPath);
// sectionName est le nom d'une section du fichier de configuration, par exemple : appSettings, connectionStrings ou des sections personnalisées
ConfigurationSection section = config.GetSection(sectionName);
// On vérifie que la section est trouvée et n'est pas déjà chiffrée
if (section != null && !section.SectionInformation.IsProtected)
{
    // On protège la section, càd qu'on la chiffre
    section.SectionInformation.ProtectSection("DataProtectionConfigurationProvider");
    // Et on enregistre le fichier de configuration
    config.Save();
}

Là aussi, deux providers : DataProtectionConfigurationProvider (EN) ou RsaProtectedConfigurationProvider (EN).

Dans cet exemple, on aura donc :

  <connectionStrings configProtectionProvider="DataProtectionConfigurationProvider">
    <EncryptedData>
      <CipherData>
        <CipherValue>AQAAANCMnd8BFdERjHoAwE/Cl+sBAAAAaA+kGY0LgkyXzrDFAOauTAQAAAACAAAAAAADZgAAwAAAABAAAAAoJF7iYn4rd14SiHAgiboKAAAAAASAAACgAAAAEAAAAJ4kiR53/KBDsLRcjjZjMikQAwAA/mk4M2e1e2F2KccbmGJD2Gfl96Igrx0tM6vFIHNFsOZ4u0/XU9lRcJ+bD2raltJ7G8PnpuUXOmDpssI/oE32S/YqLya2AW4bg6wTzaCMZ9QErrWK7Po8yI8uWDG6BHZ0iePLwi2Pa3JicKNKSrjEfCJcC7dSkpsMnSf+tuEceuOSH0PpFD6DlAz+6MFxkMs8HdAVHGmD3/EbvxjyTT1DWkPJrt8nmeViKzI9WuU8I2SbBGuRZ3ljN3lZywaN43fn5GmBE5K3gx6LTkO+RHZkMNoL13DhCPGWLQyDeRdd/gNlUYD5bdRENQLIJ9l7B5F98ygPp3T1pQqOjjURgPX/sZ0pEnBx8CFf0FRav3jWLItCuzL9vP071ivARlWUiFe0ei5Byyp7WD/fXiU+qOK0Xq00poQv3SjT01i4F0WJPe6Scrc3IEKAAqL+5W10g1G0ZHEdBl0QdqDZCrNYxf+zLrCauWYNbFesik6NGNururcDaWQk98rR/dyL6sZLVrNYkdrdKohZUrIkhmhiVX4VYeLJZxFTewS5Xvu0OhvxzbC+MbQb+NtYa6BjXjFmn8kYjl6V0mtnScPqkb8OtheLQjg0pfnAwGsLaReqg0PlGw4Figsh6uhJj/npV2ChFbALfZnxQSUTPS006A7RYubzNIJM78ZahrrUdAlKSEEsDWa1IkT7zvZx6u5ZMyProGpnQx6vvpr4x7dtmhNqJutsLd6y/TPjNdUJ1Q7AEBzMXPaDBxNPW+8iaH+rVTWJ2OHXaGcCotxWaQpRPN7fVxlLRkUDuAUKwAkkc96z1cQkfOBpK21Cxx8Y39f2qHWPh+mAiOGp404VU1WDlxxGqZPuWe2M339hbTaeY2dR2jmhPX/iVyfOuxZlmuxj3WGrfko1nVIfvWQDT4wZe9KlU47AMQ6AzVz1q10uh0XwidPAVq80Eph7p0irFvlIs3GPjuVQLojiYJ/Dsseua3cL7F5xMyhIZSlTk1XsA1u1M9cRUS+bz4XZNveejvFFu5XT2FHkKMJ6K7FgF0fGT/Qaa6CJshQAAACGu0olNAz+Jnslg44F6YKPRjHN3A==</CipherValue>
      </CipherData>
    </EncryptedData>
  </connectionStrings>

Cependant, un point important.
Si les sections appSettings et connectionStrings ne posent pas de problème, les sections personnalisées, elles, vont se révéler plus casse-pieds.
En effet, pour chiffrer une section, il faut déjà pouvoir charger TOUTES les assemblies qui sont liées dans l’AppDomain, ce qui n’est pas forcément le cas dans le cadre d’une application externe.
Je reviendrais là-dessus dans le cadre d’un autre billet.

Pour déchiffrer la section, c’est à peu près le même code :

if (section != null && section.SectionInformation.IsProtected)
{
    section.SectionInformation.UnprotectSection(); // La différence est là
    config.Save();
}

Au final, le chiffrage en lui-même n’est pas si complexe à mettre en place.

 

Aller plus loin

 

Là, je ne vais mettre qu’un seul et unique lien : Encrypting Configuration Information Using Protected Configuration (EN) étant donné que ça reste un très gros morceau à lire.

Catégories :.Net, C#, Développement, Sécurité
  1. 22/08/2013 à 16:28
    • 23/08/2013 à 09:46

      Effectivement !
      Mais pour le coup, c’est quand même bon de rappeler cette possibilité🙂

  2. 27/08/2013 à 10:02

    J’approuve totalement !

  1. 30/07/2013 à 18:43
  2. 05/08/2013 à 20:00
  3. 07/08/2013 à 22:39

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :