Løse feil i Vis status melding godkjenning kode (MAC)

Hva er visningsstatus?

Visningsstatusen er informasjon som er runde aktiveres mellom webskjemaer (aspx) sider i et ASP.NET-program. HTML-koden for __VIEWSTATE-felt ligner på følgende:

< input type = "skjulte" name = "__VIEWSTATE" id = "__VIEWSTATE" value = "..." / > Et eksempel på et element som kan være lagret i __VIEWSTATE-feltet er tekst for en knappekontroll. Hvis en bruker klikker knappen, kunne hendelsesbehandlingen Button_Click trekke ut tekst for knappen fra Vis status-feltet. Se emnet ASP.NET Vis status oversikt på webområdet Microsoft Developer Network (MSDN) for en mye mer detaljert oversikt over ASP.NET-visningsstatus.Fordi __VIEWSTATE-feltet inneholder viktig informasjon som brukes til å rekonstruere siden på tilbakesending, må du kontrollere at en angriper ikke kan endre dette feltet. Hvis en angriper sendte en skadelig __VIEWSTATE-nyttelast, kan angriperen potensielt lure programmet i utfører en handling som det ellers ikke ville har utført.Hvis du vil hindre denne typen forfalskning angrep, er __VIEWSTATE-feltet beskyttet av en melding godkjenningskode (MAC). ASP.NET validerer MAC som sendes sammen med __VIEWSTATE-nyttelast når det oppstår en tilbakesending. Nøkkelen som brukes til å beregne MAC er angitt i programmets element i Web.config-filen. Fordi angriperen ikke kan gjette innholdet i < machineKey >-elementet, kan angriperen ikke gi en gyldig MAC hvis angriperen prøver å manipulere __VIEWSTATE-nyttelast. ASP.NET vil oppdage at en gyldig MAC ikke er tilgjengelig, og ASP.NET avviser ondsinnet forespørsel.

Hva forårsaker feil i datavalideringen for MAC?

En feil ved validering av MAC vil ligne på følgende eksempel:

Serverfeil i applikasjon /.Validering av MAC for visningsstatus mislyktes. Hvis dette programmet ligger på en webserverklynge eller klynge, må du kontrollere at < > machineKey til angir samme validationKey og algoritmen. Bruke kan ikke AutoGenerate i en klynge.Beskrivelse: Det oppstod et ubehandlet unntak under kjøring av gjeldende webforespørsel. Gå gjennom stakksporingen Hvis du vil ha mer informasjon om feilen og hvor den oppstod i koden.Unntaksdetaljer: System.Web.HttpException: validering av MAC for visningsstatus mislyktes. Hvis dette programmet ligger på en webserverklynge eller klynge, må du kontrollere at < > machineKey til angir samme validationKey og algoritmen. Bruke kan ikke AutoGenerate i en klynge.Kildefeil: [Ingen relevante kildelinjer]Kildefilen:... Linje: 0Stakksporing:[ViewStateException: Ugyldig visningstilstand.Klienten IP::: 1Port: 40653Referent: http://localhost:40643/MyPage.aspxBane: /MyPage.aspxUser-Agent: Mozilla 5.0 (kompatibel; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)Visningsstatus:...][HttpException (0x80004005): validering av MAC for visningsstatus mislyktes. Hvis dette programmet ligger på en webserverklynge eller klynge, må du kontrollere at < > machineKey til angir samme validationKey og algoritmen. Bruke kan ikke AutoGenerate i en klynge.Se http://go.microsoft.com/fwlink/?LinkID=314055 for mer informasjon.]System.Web.UI.ViewStateException.ThrowError (indre unntak, String persistedState, String errorPageMessage, boolsk macValidationError) +190System.Web.UI.ViewStateException.ThrowMacValidationError (unntak indre, String persistedState) + 46System.Web.UI.ObjectStateFormatter.Deserialize (String inputString, formål formål) +861System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter2.Deserialize (String serializedState, formål formål) +51System.Web.UI.Util.DeserializeWithAssert (IStateFormatter2 formatter, String serializedState, formål formål) +67System.Web.UI.HiddenFieldPageStatePersister.Load() +444System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +368System.Web.UI.Page.LoadAllState() +109System.Web.UI.Page.ProcessRequestMain (boolsk includeStagesBeforeAsyncPoint, boolske includeStagesAfterAsyncPoint) +7959System.Web.UI.Page.ProcessRequest (boolsk includeStagesBeforeAsyncPoint, boolske includeStagesAfterAsyncPoint) +429System.Web.UI.Page.ProcessRequest() +125System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +48System.Web.UI.Page.ProcessRequest(HttpContext context) +234ASP.mypage_aspx. OneNote.ashx (HttpContext kontekst) i...: 0System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +1300System.Web.HttpApplication.ExecuteStep (IExecutionStep trinn, boolsk & completedSynchronously) +140

Årsak 1: Web-applikasjonen kjører i en farm (multiservermiljø)

ASP.NET automatisk genererer en krypteringsnøkkel for hvert program og lagre nøkkelen i registerstrukturen HKCU. Dette automatisk genererte nøkkelen brukes hvis det er ingen eksplisitt < machineKey >-elementet i Programkonfigurasjonen. Fordi denne autogenerert nøkkelen er lokalt på datamaskinen som opprettet nøkkelen, forårsaker dette scenariet problemer for programmer som kjører i en farm. Hver server i farmen vil generere sin egen lokale nøkkel, og ingen av serverne i farmen blir enige om hvilken tast som skal brukes. Resultatet er at hvis én server genererer en __VIEWSTATE-nyttelast, som bruker en annen server, forbrukeren vil det oppstå en feil under validering av MAC.

Løsning 1a: opprette et eksplisitt < machineKey >-elementLegger til et eksplisitt < machineKey >-element i Web.config-filen for programmet, forteller utvikleren ASP.NET ikke å bruke den kryptografiske nøkkelen automatisk generert. Se tillegg A for instruksjoner om hvordan du genererer et < machineKey >-elementet. Når dette elementet er lagt til i filen Web.config, kan du distribuere programmet til hver server i farmen. Obs! Noen vertstjenester for weben, for eksempel Microsoft Azure webområder, ta forholdsregler for å synkronisere automatisk generert nøkkel for hver applikasjon på tvers av deres-bakservere. Dette gjør at programmer som ikke har angitt et eksplisitt < machineKey >-element for å fortsette å arbeide i disse miljøene, selv om programmet kjører i en farm. Hvis programmet kjører på en tredjeparts-vertstjeneste, kan du kontakte din vertsleverandøren for å finne ut om dette gjelder for deg.
Oppløsning 1b: Aktiver affinitet i belastningsfordelerenHvis områdene opererer bak en belastningsfordeling, kan du aktivere serveren affinitet å omgå problemet midlertidig. Dette sikrer at alle gitt klienten bare samhandler med én fysisk server bak belastningsfordeleren slik at alle kryptografiske payloaden blir både generert av og brukes av den samme serveren.Dette bør ikke anses som en langsiktig løsning på problemet. Selv når serveren affinitet er aktivert, vil de fleste belastningsfordeling omadressere klienten til en annen fysisk server hvis den opprinnelige serveren for belastningsfordeling er affinitized som kobles fra. Dette fører til den nye serveren avviser kryptografiske payloaden som klienten har (for eksempel __VIEWSTATE, billetter til godkjenning av skjemaer, MVCs Anti forfalsket tokener og andre tjenester).Ved hjelp av en eksplisitt < machineKey >-elementet og redistribuering av programmet bør være foretrukket over å aktivere serveren affinitet.

Årsak 2: Arbeidsprosessen bruker identitet for programutvalg for IIS 7.0

Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) introdusert identitet for programutvalg foren ny isolasjon mekanisme som bidrar til gir øke sikkerheten for servere som kjører ASP.NET-programmer. Områder som kjører under programutvalgsidentiteten har imidlertid ikke tilgang til HKCU-registret. Dette er hvor ASP.NET-kjøretiden lagrer de automatisk genererte < machineKey > nøklene. Resultatet er at ASP.NET ikke kan beholde generert automatisk nøkkelen når applikasjonsutvalget tilbakestilles. Derfor hver gang w3wp.exe tilbakestilles, genereres det en ny midlertidig nøkkel. Obs! Dette er ikke et problem i IIS 7.5 (Windows 7, Windows Server 2008 R2) og senere versjoner. ASP.NET kan opprettholde de automatisk genererte nøklene i et annet sted som forsatt være gyldig selv application pool tilbakestiller på disse versjonene av IIS.

Oppløsning 2a: bruke aspnet_regiis-verktøyetASP.NET-installasjoner inneholder et verktøy, aspnet_regiis.exe. Dette verktøyet lar ASP.NET-grensesnitt med IIS til å utføre konfigurasjonene som er nødvendige for å kjøre et administrert program. En av disse konfigurasjonene oppretter de nødvendige nøklene i registerstrukturen for å aktivere holdbarheten for automatisk generert maskinnøkler.Du må først bestemme hvilket applikasjonsutvalg området bruker. Dette kan bestemmes ved hjelp av inetmgr -verktøyet som følger med IIS. Velg området i trevisningen til venstre, høyreklikk Administrere Website, og klikk deretter Avanserte innstillinger. Dialogboksen som vises, vises navnet på applikasjonsutvalget.Hvis du vil scaffold de aktuelle registernøklene for et applikasjonsutvalg ASP.NET 4.0, følger du denne fremgangsmåten:
1. Åpne en administrativ ledetekst.
2. Finn den aktuelle mappen, avhengig av om din applikasjonsutvalget er 32-biters eller 64-biters:
  - 32-biters programutvalg: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
  - 64-biters programutvalg: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319
3. Flytt til mappe, skriver du inn følgende kommando og trykker Enter:
  
  aspnet_regiis - ga "IIS APPPOOL\app-pool-navn"
Hvis applikasjonsutvalget er en ASP.NET 2.0 eller 3,5 programutvalget, gjør du følgende:
1. Åpne en administrativ ledetekst.
2. Finn den aktuelle mappen, avhengig av om din applikasjonsutvalget er 32-biters eller 64-biters:
  - 32-biters programutvalg: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
  - 64-biters programutvalg: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727
3. Flytt til mappe, skriver du inn følgende kommando og trykker Enter:
  
  aspnet_regiis - ga "IIS APPPOOL\app-pool-navn"
Hvis din programutvalget som heter Min applikasjonsutvalget (som i det forrige bildet), kjører du følgende kommando:

aspnet_regiis - ga "IIS APPPOOL\My App Pool" Obs! Systemtjenester og APPHOSTSVC WAS må kanskje kjøre aspnet_regiis-verktøyet til å løse IIS APPPOOL\ * navn på riktig måte.
Oppløsning 2b: opprette et eksplisitt < machineKey >-elementLegger til et eksplisitt < machineKey >-element i Web.config-filen for programmet, forteller utvikleren ASP.NET ikke å bruke den kryptografiske nøkkelen automatisk generert. Se tillegg A for instruksjoner om hvordan du genererer et < machineKey >-elementet.

Årsak 3: Applikasjonsutvalget konfigureres ved hjelp av LoadUserProfile = USANN

Hvis applikasjonsutvalget kjører med en tilpasset identitet, IIS kan ikke har lastet inn brukerprofil for identiteten. Dette har sideeffekt av gjør det utilgjengelig for ASP.NET til å opprettholde den automatisk genererte < machineKey > HKCU-registret. Derfor vil en ny nøkkel generert automatisk bli opprettet hver gang programmet startes på nytt. Se delen Brukerprofilen på Microsofts webområde for mer informasjon.

Oppløsning 3a: bruke aspnet_regiis-verktøyetInstruksjoner for dette er den samme som oppløsningen 2a. Se dette for mer informasjon.
Oppløsning 3b: bruker en eksplisitt < machineKey >Legger til et eksplisitt < machineKey >-element i Web.config-filen for programmet, forteller utvikleren ASP.NET ikke å bruke den kryptografiske nøkkelen automatisk generert. Se tillegg A for instruksjoner om hvordan du genererer et < machineKey >-elementet.
Løsning 3c: klargjøre de nødvendige HKCU-registernøklene manueltHvis du ikke kan kjøre aspnet_regiis-verktøyet, kan du bruke en Windows PowerShell-skriptet til å klargjøre de aktuelle registernøklene i HKCU. Se Tillegg B Hvis du vil ha mer informasjon.
Oppløsning 3d: Set LoadUserProfile = true for dette programutvalgetDu kan også aktivere laster inn brukerprofil i dette applikasjonsutvalget. Dette gjør registerstrukturen HKCU, midlertidig mappe og andre lagringssteder, brukerspesifikke tilgjengelig for programmet. Dette kan imidlertid føre til økt bruk av diskplass eller minne for arbeidsprosessen. Se elementet Hvis du vil ha mer informasjon om hvordan du aktiverer denne innstillingen.

Årsak 4: Egenskapen Page.ViewStateUserKey har en ugyldig verdi

Programvareutviklere kan velge å bruke egenskapen Page.ViewStateUserKey til å legge til forespørselen om områdedekkende forfalsket beskyttelse i feltet __VIEWSTATE. Hvis du bruker egenskapen Page.ViewStateUserKey , er det vanligvis satt til en verdi, for eksempel gjeldende brukers brukernavn eller brukerens økt-ID. Project-maler for webskjemaer programmer i Microsoft Visual Studio 2012 og senere versjoner inneholder eksempler som bruker denne egenskapen. Se egenskapsemnet Page.ViewStateUserKey på webområdet Microsoft Developer Network (MSDN) for mer informasjon.Hvis egenskapen ViewStateUserKey er angitt, er verdien brent til __VIEWSTATE generasjon samtidig. Når feltet __VIEWSTATE er brukt, serveren kontrollerer ViewStateUserKey -egenskapen for den gjeldende siden, og validerer den mot verdien som ble brukt til å generere __VIEWSTATE-feltet. Hvis verdiene ikke samsvarer, avvist blir forespørselen som potensielt skadelig.Et eksempel på en ViewStateUserKey-relaterte feil kan være en klient som har to faner åpne i webleseren. Klienten er logget på som bruker A, og i den første kategorien, vises en side med en __VIEWSTATE med ViewStateUserKey -egenskapen inneholder "Bruker A." I den andre kategorien klienten logger av og deretter logger på som bruker B. Klienten sender skjemaet, og går tilbake til den første kategorien. Egenskapen ViewStateUserKey kan inneholde "Bruker B" (fordi det er informasjonskapsler for godkjenning av klientens sier). Feltet __VIEWSTATE som klienten sendte inneholder imidlertid "Bruker A." Denne konflikten fører til feil.

4a løsning: Kontroller at ViewStateUserKey er riktig angittHvis programmet bruker egenskapen ViewStateUserKey , må du kontrollere at egenskapsverdien er de samme både når det genereres visningsstatus, og når den er brukt. Hvis du bruker gjeldende påloggede brukers brukernavn, må du kontrollere at brukeren fremdeles er logget på og at brukerens identitet ikke er endret på tidspunktet for tilbakesending. Hvis du bruker gjeldende brukers økt-ID, må du kontrollere at økten ikke tidsavbrutt.Hvis du kjører i et farmmiljø, kontrollerer du at < machineKey > objektene samsvarer. Se tillegg A for å få instruksjoner om hvordan du genererer disse elementene.

Tillegg A: hvordan du genererer et < machineKey >-element

SikkerhetsadvarselDet finnes mange web-områder som vil generere en < machineKey >-elementet for deg ved å klikke en knapp. Bruk aldri et < machineKey >-element som du fikk fra en av disse områdene. Det er umulig å vite om disse nøklene ble opprettet på en sikker måte, eller hvis de spilles til en hemmelig database. Du bør bare noen gang bruke < machineKey > konfigurasjon elementer som du har opprettet selv.

Hvis du vil generere en < machineKey >-elementet selv, kan du bruke Windows PowerShell -skriptet nedenfor:

# 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)
  }
}

Du kan bare kalle Generer MachineKey for ASP.NET 4.0-programmer, uten parametere for å generere en < machineKey >-elementet som følger:

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

ASP.NET 2.0- og 3.5-programmer støtter ikke HMACSHA256. I stedet kan du angi SHA1 for å generere en kompatibel < machineKey >-elementet som følger:

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

Så snart du har en < machineKey >-elementet, kan du legge den inn i Web.config-filen. < MachineKey >-elementet er bare gyldige i filen Web.config i roten av programmet, og er ikke gyldig på undermappe nivå.

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

For en fullstendig liste over støttede algoritmer, kjøre å generere MachineKey fra Windows PowerShell-ledeteksten.

Tillegg B: klargjøring av registret for å beholde automatisk genererte nøkler

Som standard, fordi ASP.NETs automatisk genererte nøkler er beholdt i HKCU-registret kan disse nøklene gå tapt hvis brukerprofilen ikke lastet inn i IIS-arbeidsprosessen og deretter applikasjonsutvalget resirkuleres. Dette scenariet kan påvirke delte vert leverandører som kjører programutvalg som standard Windows-brukerkontoer.Hvis du vil unngå denne situasjonen, aktiverer ASP.NET persisting tastene automatisk generert i HKLM registret i stedet for HKCU-registret. Dette er vanligvis utføres ved hjelp av aspnet_regiis-verktøyet (se instruksjonene i den "oppløsning 2a: bruke aspnet_regiis-verktøyet" delen). Men for administratorer som ikke ønsker å kjøre dette verktøyet, kan følgende Windows PowerShell -skriptet brukes i stedet:

# 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)
    }
  }
}

Følgende eksempel viser hvordan du klargjør riktig HKLM registeroppføringene for et applikasjonsutvalg som kjører som bruker example@contoso.com (dette er UPN av Windows-brukerkontoen). Dette applikasjonsutvalget er et 32-biters programutvalg som kjører CLR-v2.0 (ASP.NET 2.0 eller 3,5-tommers).

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

Hvis applikasjonsutvalget er i stedet et 64-biters programutvalg som kjører CLR v4.0 (ASP.NET 4.0 eller 4.5), er kommandoen som følger:

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

Selv om de automatisk genererte nøklene lagres i HKLM, legges registerundernøkkelen som inneholder hver brukerkonto hemmelig kryptografiske materiale til en tilgangskontrolliste (ACL) slik at det kryptografiske materialet ikke kan leses av andre brukerkontoer.

Tillegg C: kryptere < machineKey >-elementet i konfigurasjonsfiler

Server-administratorer vil kanskje ikke svært følsom informasjon, for eksempel < machineKey > nøkkelen regning til bein ren tekst-skjemaet i konfigurasjonsfilene. Hvis dette er tilfellet, kan administratorer velge å dra nytte av en .NET Framework-funksjon kalt "beskyttet konfigurasjon." Denne funksjonen lar deg kryptere bestemte deler av .config-filer. Hvis innholdet i disse konfigurasjonsfiler noensinne er publisert, forblir innholdet i disse delene, hemmelig.Du kan finne en kort oversikt over beskyttet konfigurasjon på MSDN-webområdet. Den inneholder også en veiledning om hvordan du beskytter < connectionStrings > og < machineKey > elementer i Web.config-filen.