Beheben von MAC-Fehlern (View State Message Authentication Code, Authentifizierungscode) für den Ansichtsstatus

Was ist der Ansichtszustand?

Der Ansichtsstatus ist eine Information, die zwischen WebForms (.aspx)-Seiten in einer ASP.NET Anwendung ausgetauscht wird. Das HTML-Markup für das Feld __VIEWSTATE sieht etwa wie folgt aus:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
Ein Beispiel für ein Element, das im Feld "__VIEWSTATE" gespeichert werden kann, ist der Text eines Button-Steuerelements. Wenn ein Benutzer auf die Schaltfläche klickt, kann der Button_Click-Ereignishandler den Text der Schaltfläche aus dem Ansichtszustandsfeld extrahieren. Eine ausführlichere Übersicht über den ASP.NET-Ansichtsstatus finden Sie auf der MSDN-Website (MSDN) unter dem Thema "Übersicht über den ASP.NET Ansichtsstatus ".

Da das Feld __VIEWSTATE wichtige Informationen enthält, die verwendet werden, um die Seite beim Postback zu rekonstruieren, stellen Sie sicher, dass ein Angreifer dieses Feld nicht manipulieren kann. Wenn ein Angreifer eine schädliche __VIEWSTATE Nutzlast übermittelt, könnte der Angreifer die Anwendung möglicherweise dazu verleiten, eine Aktion auszuführen, die sie andernfalls nicht ausgeführt hätte.

Um diese Art von Manipulationsangriffen zu verhindern, wird das __VIEWSTATE Feld durch einen Nachrichtenauthentifizierungscode (Message Authentication Code, MAC) geschützt. ASP.NET überprüft die MAC, die zusammen mit der __VIEWSTATE-Nutzlast übermittelt wird, wenn ein Postback auftritt. Der Schlüssel, der zur Berechnung der MAC verwendet wird, wird im Element der Anwendung in der Web.config Datei angegeben. Da der Angreifer den Inhalt des <machineKey-Elements> nicht erraten kann, können sie keine gültige MAC bereitstellen, wenn sie versuchen, die __VIEWSTATE Nutzlast zu manipulieren. ASP.NET erkennt, dass keine gültige MAC angegeben wurde, und ASP.NET die böswillige Anforderung ablehnen.

Was verursacht Fehler bei der MAC-Überprüfung?

Ein MAC-Überprüfungsfehler ähnelt dem folgenden Beispiel:

Ursache 1: Die Webanwendung wird in einer Farm (Multi-Server-Umgebung) ausgeführt

ASP.NET generiert automatisch einen Kryptografieschlüssel für jede Anwendung und speichert den Schlüssel in der HKCU-Registrierungsstruktur. Dieser automatisch generierte Schlüssel wird verwendet, wenn kein explizites <machineKey-Element> in der Anwendungskonfiguration vorhanden ist. Da sich dieser automatisch generierte Schlüssel jedoch lokal auf dem Computer befindet, der den Schlüssel erstellt hat, verursacht dieses Szenario ein Problem für Anwendungen, die in einer Farm ausgeführt werden. Jeder Server in der Farm generiert seinen eigenen lokalen Schlüssel, und keiner der Server in der Farm stimmt zu, welcher Schlüssel verwendet werden soll. Wenn ein Server eine __VIEWSTATE Nutzlast generiert, die ein anderer Server verbraucht, tritt für den Verbraucher ein Fehler bei der MAC-Validierung auf.

• Lösung 1a: Erstellen eines expliziten <machineKey-Elements>

  Durch Hinzufügen eines expliziten <machineKey-Elements> zur Web.config Datei der Anwendung weist der Entwickler ASP.NET an, den automatisch generierten kryptografischen Schlüssel nicht zu verwenden. Anweisungen zum Generieren eines <machineKey-Elements> finden Sie in Anhang A. Nachdem dieses Element der Web.config Datei hinzugefügt wurde, stellen Sie die Anwendung auf jedem Server in der Farm erneut bereit.

  Hinweis Einige Webhostingdienste, z. B. Microsoft Azure-Websites, unternehmen Schritte, um den automatisch generierten Schlüssel jeder Anwendung über ihre Back-End-Server hinweg zu synchronisieren. Auf diese Weise können Anwendungen, die kein explizites <machineKey-Element> angegeben haben, weiterhin in diesen Umgebungen arbeiten, auch wenn die Anwendung in einer Farm ausgeführt wird. Wenn Ihre Anwendung auf einem Hostingdienst eines Drittanbieters ausgeführt wird, wenden Sie sich bitte an Ihren Hostinganbieter, um festzustellen, ob diese Situation auf Sie zutrifft.

• Lösung 1b: Aktivieren der Affinität im Load Balancer

  Wenn Ihre Websites hinter einem Load Balancer ausgeführt werden, können Sie die Serveraffinität aktivieren, um das Problem vorübergehend zu umgehen. Dadurch wird sichergestellt, dass ein bestimmter Client nur mit einem physischen Server hinter dem Load Balancer interagiert, sodass alle kryptografischen Nutzlasten vom selben Server generiert und von demselben genutzt werden.

  Dies sollte nicht als langfristige Lösung des Problems angesehen werden. Selbst wenn die Serveraffinität aktiviert ist, leiten die meisten Load Balancer den Client zu einem anderen physischen Server um, wenn der ursprüngliche Server, dem die Load Balancer zugeordnet wurden, offline geht. Dies führt dazu, dass der neue Server kryptografische Nutzlasten (z. B. __VIEWSTATE, Formularauthentifizierungstickets, MVCs, fälschungsgeschützte Token und andere Dienste) ablehnt, über die der Client derzeit verfügt.

  Die Verwendung eines expliziten <machineKey-Elements> und die erneute Bereitstellung der Anwendung sollte der Aktivierung der Serveraffinität vorgezogen werden.

Ursache 2: Der Arbeitsprozess verwendet die IIS 7.0-Anwendungspoolidentität.

In Internetinformationsdienste (IIS) 7.0 (Windows Vista, Windows Server 2008) wurde die Anwendungspoolidentität eingeführt, ein neuer Isolationsmechanismus, der Servern, auf denen ASP.NET Anwendungen ausgeführt werden, mehr Sicherheit bietet. Websites, die unter der Anwendungspoolidentität ausgeführt werden, haben jedoch keinen Zugriff auf die HKCU-Registrierung. Hier speichert die ASP.NET Runtime ihre automatisch generierten <machineKey-Schlüssel> . Dies hat zur Folge, dass ASP.NET den automatisch generierten Schlüssel beim Zurücksetzen des Anwendungspools nicht mehr beibehalten können. Daher wird jedes Mal, wenn w3wp.exe zurückgesetzt wird, ein neuer temporärer Schlüssel generiert.

Hinweis: In IIS 7.5 (Windows 7, Windows Server 2008 R2) und höheren Versionen ist dies kein Problem. In diesen Versionen von IIS können ASP.NET ihre automatisch generierten Schlüssel an einem anderen Speicherort beibehalten, der das Zurücksetzen des Anwendungspools überdauert.

• Lösung 2a: Verwenden des Hilfsprogramms aspnet_regiis

  ASP.NET Installationen ein Dienstprogramm enthalten, aspnet_regiis.exe. Dieses Hilfsprogramm ermöglicht ASP.NET Schnittstelle mit IIS, um die Konfigurationen durchzuführen, die zum Ausführen einer verwalteten Anwendung erforderlich sind. Eine dieser Konfigurationen erstellt die erforderlichen Schlüssel in der Registrierungsstruktur, um die Persistenz automatisch generierter Computerschlüssel zu ermöglichen.

  Zunächst müssen Sie ermitteln, welchen Anwendungspool Ihre Website verwendet. Dies kann mithilfe des Hilfsprogramms "inetmgr" ermittelt werden, das in IIS enthalten ist. Wählen Sie Ihre Website in der Strukturansicht auf der linken Seite aus, klicken Sie mit der rechten Maustaste auf Websit verwaltenund klicken Sie dann auf Erweiterte Einstellungen. Im daraufhin angezeigten Dialogfeld wird der Name des Anwendungspools angezeigt.

  

  Gehen Sie folgendermaßen vor, um die geeigneten Registrierungsschlüssel für einen ASP.NET 4.0-Anwendungspool zu erstellen:

  1. Öffnen Sie eine Eingabeaufforderung als Administrator.

  2. Suchen Sie das entsprechende Verzeichnis, je nachdem, ob es sich bei Ihrem Anwendungspool um eine 32-Bit- oder 64-Bit-Version handelt:

     • 32-Bit-Anwendungspool: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
     • 64-Bit-Anwendungspool: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

  3. Wechseln Sie zum Verzeichnis, geben Sie den folgenden Befehl ein, und drücken Sie dann die Eingabetaste:

     aspnet_regiis -ga "IIS APPPOOL\app-pool-name"

  Wenn es sich bei dem Anwendungspool um einen ASP.NET 2.0- oder 3.5-Anwendungspool handelt, führen Sie die folgenden Schritte aus:

  1. Öffnen Sie eine Eingabeaufforderung als Administrator.

  2. Suchen Sie das entsprechende Verzeichnis, je nachdem, ob es sich bei Ihrem Anwendungspool um eine 32-Bit- oder 64-Bit-Version handelt:

     • 32-Bit-Anwendungspool: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
     • 64-Bit-Anwendungspool: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

  3. Wechseln Sie zum Verzeichnis, geben Sie den folgenden Befehl ein, und drücken Sie dann die Eingabetaste:

     aspnet_regiis -ga "IIS APPPOOL\app-pool-name"

  Wenn Ihr Anwendungspool beispielsweise "Mein App-Pool" heißt (wie in der vorherigen Abbildung), führen Sie den folgenden Befehl aus:
   
  aspnet_regiis -ga "IIS APPPOOL\My App Pool"

  Hinweis: Möglicherweise müssen die Systemdienste APPHOSTSVC und WAS ausgeführt werden, damit das Dienstprogramm aspnet_regiis IIS-APPPOOL\*-Namen entsprechend auflösen kann.

• Lösung 2b: Erstellen eines expliziten <machineKey-Elements>

  Durch Hinzufügen eines expliziten <machineKey-Elements> zur Web.config Datei der Anwendung weist der Entwickler ASP.NET an, den automatisch generierten kryptografischen Schlüssel nicht zu verwenden. Anweisungen zum Generieren eines <machineKey-Elements> finden Sie in Anhang A.

Ursache 3: Der Anwendungspool wird mithilfe von "LoadUserProfile=false" konfiguriert.

Wenn der Anwendungspool mit einer benutzerdefinierten Identität ausgeführt wird, wurde das Benutzerprofil für die Identität von IIS möglicherweise nicht geladen. Dies hat den Nebeneffekt, dass die HKCU-Registrierung für ASP.NET nicht verfügbar ist, um den automatisch generierten <machineKey> beizubehalten. Daher wird bei jedem Neustart der Anwendung ein neuer automatisch generierter Schlüssel erstellt. Weitere Informationen finden Sie auf der Microsoft-Website im Abschnitt "Benutzerprofil ".

• Lösung 3a: Verwenden des Hilfsprogramms aspnet_regiis

  Die Anweisungen hierfür sind die gleichen wie bei Resolution 2a. Weitere Informationen hierzu finden Sie in diesem Abschnitt.

• Lösung 3b: Verwenden eines expliziten <machineKey>

  Durch Hinzufügen eines expliziten <machineKey-Elements> zur Web.config Datei der Anwendung weist der Entwickler ASP.NET an, den automatisch generierten kryptografischen Schlüssel nicht zu verwenden. Anweisungen zum Generieren eines <machineKey-Elements> finden Sie in Anhang A.

• Lösung 3c: Manuelles Bereitstellen der erforderlichen HKCU-Registrierungsschlüssel

  Wenn Sie das Hilfsprogramm aspnet_regiis nicht ausführen können, können Sie ein Windows PowerShell Skript verwenden, um die entsprechenden Registrierungsschlüssel in HKCU bereitzustellen. Weitere Informationen finden Sie in Anhang B .

• Auflösung 3d: Legen Sie LoadUserProfile=true für diesen Anwendungspool fest

  Sie können auch das Laden des Benutzerprofils innerhalb dieses Anwendungspools aktivieren. Dadurch werden die HKCU-Registrierungsstruktur, der temporäre Ordner und andere benutzerspezifische Speicherorte für die Anwendung verfügbar. Dies kann jedoch zu einer erhöhten Datenträger- oder Arbeitsspeicherauslastung für den Arbeitsprozess führen. Weitere Informationen zum Aktivieren dieser Einstellung finden Sie im Element .

Ursache 4: Die Page.ViewStateUserKey-Eigenschaft hat einen falschen Wert

Softwareentwickler können die Page.ViewStateUserKey-Eigenschaft verwenden, um dem Feld "__VIEWSTATE" einen Schutz vor siteübergreifender Anforderungsfälschung hinzuzufügen. Wenn Sie die Page.ViewStateUserKey-Eigenschaft verwenden, wird sie in der Regel auf einen Wert wie den Benutzernamen des aktuellen Benutzers oder die Sitzungs-ID des Benutzers festgelegt. Die Projektvorlagen für WebForms-Anwendungen in Microsoft Visual Studio 2012 und späteren Versionen enthalten Beispiele, die diese Eigenschaft verwenden. Weitere Informationen finden Sie auf der MSDN-Website (MSDN) unter dem Thema zur Eigenschaft Page.ViewStateUserKey.

Wenn die ViewStateUserKey-Eigenschaft angegeben ist, wird ihr Wert zur Generierungszeit in __VIEWSTATE eingebrannt. Wenn das __VIEWSTATE Feld verwendet wird, überprüft der Server die ViewStateUserKey-Eigenschaft der aktuellen Seite und überprüft sie anhand des Werts, der zum Generieren des __VIEWSTATE Felds verwendet wurde. Wenn die Werte nicht übereinstimmen, wird die Anforderung als potenziell schädlich abgelehnt.

Ein Beispiel für einen ViewStateUserKey-bezogenen Fehler wäre ein Client, der zwei Registerkarten im Browser geöffnet hat. Der Client wird als Benutzer A angemeldet, und auf der ersten Registerkarte wird eine Seite mit einem __VIEWSTATE gerendert, dessen ViewStateUserKey-Eigenschaft "Benutzer A" enthält. Auf der zweiten Registerkarte meldet sich der Client ab und dann wieder als Benutzer B an. Der Kunde kehrt zur ersten Registerkarte zurück und sendet das Formular ab. Die ViewStateUserKey-Eigenschaft kann "Benutzer B" enthalten, da dies im Authentifizierungscookie des Clients angegeben ist. Das __VIEWSTATE Feld, das der Client übermittelt hat, enthält jedoch "Benutzer A". Dieser Konflikt verursacht den Fehler.

• Auflösung 4a: Überprüfen, ob ViewStateUserKey richtig festgelegt ist

  Wenn Ihre Anwendung die ViewStateUserKey-Eigenschaft verwendet, stellen Sie sicher, dass der Wert der Eigenschaft sowohl beim Generieren des Ansichtszustands als auch beim Verwenden identisch ist. Wenn Sie den Benutzernamen des aktuell angemeldeten Benutzers verwenden, stellen Sie sicher, dass der Benutzer weiterhin angemeldet ist und dass sich die Identität des Benutzers zum Zeitpunkt des Postbacks nicht geändert hat. Wenn Sie die Sitzungs-ID des aktuellen Benutzers verwenden, stellen Sie sicher, dass die Sitzung nicht abgelaufen ist.

  Wenn Sie in einer Farmumgebung arbeiten, stellen Sie sicher, dass die <machineKey-Elemente> übereinstimmen. Anweisungen zum Generieren dieser Elemente finden Sie in Anhang A .

          

Anhang A: Generieren eines <machineKey-Elements>

        
Verwenden Sie das folgende Windows PowerShell-Skript, um selbst ein <machineKey-Element> zu generieren:

# Generates a <machineKey> element that can be copied + pasted into a Web.config file.
function Generate-MachineKey {
  [CmdletBinding()]
  param (
    [ValidateSet("AES", "DES", "3DES")]
    [string]$decryptionAlgorithm = 'AES',
    [ValidateSet("MD5", "SHA1", "HMACSHA256", "HMACSHA384", "HMACSHA512")]
    [string]$validationAlgorithm = 'HMACSHA256'
  )
  process {
    function BinaryToHex {
        [CmdLetBinding()]
        param($bytes)
        process {
            $builder = new-object System.Text.StringBuilder
            foreach ($b in $bytes) {
              $builder = $builder.AppendFormat([System.Globalization.CultureInfo]::InvariantCulture, "{0:X2}", $b)
            }
            $builder
        }
    }
    switch ($decryptionAlgorithm) {
      "AES" { $decryptionObject = new-object System.Security.Cryptography.AesCryptoServiceProvider }
      "DES" { $decryptionObject = new-object System.Security.Cryptography.DESCryptoServiceProvider }
      "3DES" { $decryptionObject = new-object System.Security.Cryptography.TripleDESCryptoServiceProvider }
    }
    $decryptionObject.GenerateKey()
    $decryptionKey = BinaryToHex($decryptionObject.Key)
    $decryptionObject.Dispose()
    switch ($validationAlgorithm) {
      "MD5" { $validationObject = new-object System.Security.Cryptography.HMACMD5 }
      "SHA1" { $validationObject = new-object System.Security.Cryptography.HMACSHA1 }
      "HMACSHA256" { $validationObject = new-object System.Security.Cryptography.HMACSHA256 }
      "HMACSHA385" { $validationObject = new-object System.Security.Cryptography.HMACSHA384 }
      "HMACSHA512" { $validationObject = new-object System.Security.Cryptography.HMACSHA512 }
    }
    $validationKey = BinaryToHex($validationObject.Key)
    $validationObject.Dispose()
    [string]::Format([System.Globalization.CultureInfo]::InvariantCulture,
      "<machineKey decryption=`"{0}`" decryptionKey=`"{1}`" validation=`"{2}`" validationKey=`"{3}`" />",
      $decryptionAlgorithm.ToUpperInvariant(), $decryptionKey,
      $validationAlgorithm.ToUpperInvariant(), $validationKey)
  }
}

Für ASP.NET 4.0-Anwendungen können Sie einfach Generate-MachineKey ohne Parameter aufrufen, um ein <machineKey-Element> wie folgt zu generieren:

PS> Generate-MachineKey
<machineKey decryption="AES" decryptionKey="..." validation="HMACSHA256" validationKey="..." />

ASP.NET 2.0- und 3.5-Anwendungen unterstützen HMACSHA256 nicht. Stattdessen können Sie SHA1 angeben, um ein kompatibles <machineKey-Element> wie folgt zu generieren:

PS> Generate-MachineKey -validation sha1
<machineKey decryption="AES" decryptionKey="..." validation="SHA1" validationKey="..." />

Sobald Sie über ein <machineKey-Element> verfügen, können Sie es in die Web.config Datei einfügen. Das <machineKey-Element> ist nur in der Web.config-Datei im Stammverzeichnis Ihrer Anwendung und nicht auf Unterordnerebene gültig.

<configuration>
  <system.web>
    <machineKey ... />
  </system.web>
</configuration>

Eine vollständige Liste der unterstützten Algorithmen finden Sie in der Windows PowerShell Eingabeaufforderung unter "help Generate-MachineKey".

Anhang B: Bereitstellung der Registrierung zum Beibehalten automatisch generierter Schlüssel

Da ASP. Automatisch generierte Schlüssel von NETs werden in der HKCU-Registrierung beibehalten. Diese Schlüssel können verloren gehen, wenn das Benutzerprofil nicht in den IIS-Arbeitsprozess geladen wurde und der Anwendungspool dann wiederverwendet wird. Dieses Szenario kann sich auf Shared Hosting-Anbieter auswirken, die Anwendungspools als Windows-Standardbenutzerkonten ausführen.

Um diese Situation zu umgehen, ermöglicht ASP.NET, die automatisch generierten Schlüssel in der HKLM-Registrierung anstelle der HKCU-Registrierung beizubehalten. Dies wird in der Regel mithilfe des Dienstprogramms aspnet_regiis durchgeführt (siehe Anweisungen im Abschnitt "Lösung 2a: Verwenden des Dienstprogramms aspnet_regiis"). Für Administratoren, die dieses Hilfsprogramm nicht ausführen möchten, kann stattdessen das folgende Windows PowerShell-Skript verwendet werden:

# Provisions the HKLM registry so that the specified user account can persist auto-generated machine keys.
function Provision-AutoGenKeys {
  [CmdletBinding()]
  param (
    [ValidateSet("2.0", "4.0")]
    [Parameter(Mandatory = $True)]
    [string] $frameworkVersion,
    [ValidateSet("32", "64")]
    [Parameter(Mandatory = $True)]
    [string] $architecture,
    [Parameter(Mandatory = $True)]
    [string] $upn
  )
  process {
    # We require administrative permissions to continue.
    if (-Not (new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
        Write-Error "This cmdlet requires Administrator permissions."
        return
    }
    # Open HKLM with an appropriate view into the registry
    if ($architecture -eq "32") {
        $regView = [Microsoft.Win32.RegistryView]::Registry32;
    } else {
        $regView = [Microsoft.Win32.RegistryView]::Registry64;
    }
    $baseRegKey = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, $regView)
    # Open ASP.NET base key
    if ($frameworkVersion -eq "2.0") {
        $expandedVersion = "2.0.50727.0"
    } else {
        $expandedVersion = "4.0.30319.0"
    }
    $aspNetBaseKey = $baseRegKey.OpenSubKey("SOFTWARE\Microsoft\ASP.NET\$expandedVersion", $True)
    # Create AutoGenKeys subkey if it doesn't already exist
    $autoGenBaseKey = $aspNetBaseKey.OpenSubKey("AutoGenKeys", $True)
    if ($autoGenBaseKey -eq $null) {
        $autoGenBaseKey = $aspNetBaseKey.CreateSubKey("AutoGenKeys")
    }
    # Get the SID for the user in question, which will allow us to get his AutoGenKeys subkey
    $sid = (New-Object System.Security.Principal.WindowsIdentity($upn)).User.Value
    # SYSTEM, ADMINISTRATORS, and the target SID get full access
    $regSec = New-Object System.Security.AccessControl.RegistrySecurity
    $regSec.SetSecurityDescriptorSddlForm("D:P(A;OICI;GA;;;SY)(A;OICI;GA;;;BA)(A;OICI;GA;;;$sid)")
    $userAutoGenKey = $autoGenBaseKey.OpenSubKey($sid, $True)
    if ($userAutoGenKey -eq $null) {
        # Subkey didn't exist; create and ACL appropriately
        $userAutoGenKey = $autoGenBaseKey.CreateSubKey($sid, [Microsoft.Win32.RegistryKeyPermissionCheck]::Default, $regSec)
    } else {
        # Subkey existed; make sure ACLs are correct
        $userAutoGenKey.SetAccessControl($regSec)
    }
  }
}

Im folgenden Beispiel wird gezeigt, wie die entsprechenden HKLM-Registrierungseinträge für einen Anwendungspool bereitgestellt werden, example@contoso.com der als Benutzer ausgeführt wird (dies ist der UPN des Windows-Benutzerkontos). Dieser Anwendungspool ist ein 32-Bit-Anwendungspool, auf dem die CLR v2.0 (ASP.NET 2.0 oder 3.5) ausgeführt wird.

PS> Provision-AutoGenKeys -FrameworkVersion 2.0 -Architecture 32 -UPN "example@contoso.com"

Wenn es sich bei dem Anwendungspool stattdessen um einen 64-Bit-Anwendungspool handelt, auf dem CLR v4.0 (ASP.NET 4.0 oder 4.5) ausgeführt wird, lautet der Befehl wie folgt:

PS> Provision-AutoGenKeys -FrameworkVersion 4.0 -Architecture 64 -UPN "example@contoso.com"

Obwohl die automatisch generierten Schlüssel in HKLM gespeichert werden, wird der Registrierungsunterschlüssel, der das geheime kryptografische Material jedes Benutzerkontos enthält, einer Zugriffssteuerungsliste (Access Control List, ACL) hinzugefügt, sodass das kryptografische Material nicht von anderen Benutzerkonten gelesen werden kann.

Anhang C: Verschlüsseln des <machineKey-Elements> in Konfigurationsdateien

Serveradministratoren möchten möglicherweise nicht, dass hochsensible Informationen wie das <machineKey-Schlüsselmaterial> in Konfigurationsdateien im Klartextformat vorliegen. In diesem Fall können Administratoren eine Funktion von .NET Framework nutzen, die als "geschützte Konfiguration" bezeichnet wird. Mit diesem Feature können Sie bestimmte Abschnitte der .config-Dateien verschlüsseln. Sollte der Inhalt dieser Konfigurationsdateien jemals offengelegt werden, bleibt der Inhalt dieser Abschnitte immer noch geheim.

Eine kurze Übersicht über die geschützte Konfiguration finden Sie auf der MSDN-Website. Es enthält auch ein Tutorial zum Schutz der <Elemente connectionStrings> und <machineKey> der Web.config Datei.