ビュー ステート メッセージ認証コード (MAC) エラーの解決

ビュー ステートとは

ビュー状態は、ASP.NET アプリケーションの WebForms (.aspx) ページ間でラウンドトリップされる情報です。 __VIEWSTATE フィールドの HTML マークアップは、次のようになります。

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
__VIEWSTATE フィールドに格納される可能性があるアイテムの 1 つの例は、Button コントロールのテキストです。 ユーザーがボタンをクリックすると、Button_Click イベント ハンドラーはビュー ステート フィールドからボタンのテキストを抽出できます。 ASP.NET ビュー ステートの詳細については、Microsoft Developer Network (MSDN) Web サイトの「 ASP.NET ビュー ステートの概要 」を参照してください。

__VIEWSTATE フィールドには、ポストバック時にページを再構築するために使用される重要な情報が含まれているため、攻撃者がこのフィールドを改ざんできないことを確認してください。 攻撃者が悪意のある __VIEWSTATE ペイロードを送信した場合、攻撃者はアプリケーションをだまして、他の方法では実行しなかったアクションを実行させる可能性があります。

この種の改ざんを防ぐために、__VIEWSTATE フィールドはメッセージ認証コード (MAC) によって保護されます。 ASP.NET は、ポストバックが発生したときに、__VIEWSTATE ペイロードと共に送信される MAC を検証します。 MAC の計算に使用されるキーは、Web.config ファイルのアプリケーションの 要素 に指定されます。 攻撃者は <machineKey> 要素の内容を推測できないため、攻撃者が __VIEWSTATE ペイロードを改ざんしようとした場合、有効な MAC を提供できません。 ASP.NET は有効な MAC が提供されていないことを検出し、悪意のある要求を拒否 ASP.NET。

MAC 検証エラーの原因は何ですか?

MAC 検証エラーは、次の例のようになります。

原因 1: Web アプリケーションがファーム (マルチサーバー環境) で実行されている

ASP.NET では、アプリケーションごとに自動的に暗号化キーが作成され、そのキーが HKCU レジストリ ハイブに保存されます。 この自動生成されたキーは、アプリケーションの構成に明示的な <machineKey> 要素がない場合に使用されます。 ただし、この自動生成されたキーはキーを作成したコンピューターに対してローカルであるため、このシナリオでは、ファームで実行されるアプリケーションで問題が発生します。 ファーム内の各サーバーは独自のローカル キーを生成し、ファーム内のどのサーバーも使用するキーについて同意しません。 その結果、1 つのサーバーが別のサーバーが使用する __VIEWSTATE ペイロードを生成すると、コンシューマーは MAC 検証エラーを経験します。

• 解決策 1a: 明示的な <machineKey> 要素を作成する

  明示的な <machineKey> 要素をアプリケーションの Web.config ファイルに追加することで、開発者は自動生成された暗号化キーを使用しないように ASP.NET に指示します。 <machineKey> 要素を生成する方法については、付録 A を参照してください。 この要素を Web.config ファイルに追加したら、ファーム内の各サーバーにアプリケーションを再デプロイします。

  注: Microsoft Azure Web サイトなどの一部の Web ホスティング サービスでは、バックエンド サーバー間で各アプリケーションの自動生成キーを同期する手順を実行します。 これにより、明示的な <machineKey> 要素を指定していないアプリケーションは、アプリケーションがファームで実行されている場合でも、これらの環境で動作を続行できます。 アプリケーションがサードパーティのホスティング サービスで実行されている場合、この状況が当てはまるかどうかを確認するには、ホスティング プロバイダーにお問い合わせください。

• 解決策 1b: ロード バランサーでアフィニティを有効にする

  サイトがロード バランサーの背後で動作している場合は、サーバー アフィニティを有効にして一時的に問題を回避できます。 これにより、特定のクライアントがロード バランサーの背後にある 1 つの物理サーバーとのみ対話することが保証されるため、すべての暗号化ペイロードは同じサーバーで生成され、同じサーバーによって使用されます。

  これは、問題の長期的な解決策と見なすべきではありません。 サーバー・アフィニティが有効になっている場合でも、ロード・バランサーがアフィニティ化された元のサーバーがオフラインになった場合、ほとんどのロード・バランサーはクライアントを別の物理サーバーにリダイレクトします。 これにより、新しいサーバーは、クライアントが現在持っている暗号化ペイロード (__VIEWSTATE、フォーム認証チケット、MVC、偽造防止トークン、その他のサービスなど) を拒否します。

  明示的な <machineKey> 要素を使用し、アプリケーションを再デプロイする方が、サーバー アフィニティを有効にするよりも優先されます。

原因 2: ワーカー プロセスが IIS 7.0 アプリケーション プール id を使用する

インターネット インフォメーション サービス (IIS) 7.0 (Windows Vista、Windows Server 2008) では、アプリケーション プール ID が導入されました。これは、ASP.NET アプリケーションを実行するサーバーのセキュリティを強化するのに役立つ新しい分離メカニズムです。 ただし、アプリケーション プール id で実行されているサイトは、HKCU レジストリにアクセスできません。 ここには、ASP.NET ランタイムが自動生成された <machineKey> キーを格納する場所です。 その結果、アプリケーション プール ASP.NET リセットされたときに自動生成されたキーを保持できません。 そのため、w3wp.exe がリセットされるたびに、新しい一時キーが生成されます。

注: これは、IIS 7.5 (Windows 7、Windows Server 2008 R2) 以降のバージョンでは問題ではありません。 これらの IIS のバージョンでは、ASP.NET は自動生成されたキーを別の場所に保持して、アプリケーション プールのリセット後も存続することができます。

• 解決策 2a: aspnet_regiis ユーティリティを使用する

  ASP.NET インストールには、 ユーティリティaspnet_regiis.exeが含まれています。 このユーティリティを使用すると、ASP.NET IIS とインターフェイスして、マネージド アプリケーションの実行に必要な構成を実行できます。 これらの構成の 1 つにより、自動生成されたマシン キーの永続化を有効にするために必要なキーがレジストリ ハイブに作成されます。

  まず、サイトで使用しているアプリケーション プールを特定する必要があります。 これは、IIS に含まれている inetmgr ユーティリティを使用して確認できます。 左側のツリー ビューでサイトを選択し、[ Web サイトの管理] を右クリックして、[ 詳細設定] をクリックします。 ダイアログ ボックスにアプリケーション プール名が表示されます。

  

  ASP.NET 4.0 アプリケーション プールに適切なレジストリ キーをスキャフォールドするには、次の手順を実行します。

  1. 管理コマンド プロンプトを開きます。

  2. アプリケーション プールが 32 ビットか 64 ビットかに応じて、適切なディレクトリを見つけます。

     • 32 ビット アプリケーション プール: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
     • 64 ビット アプリケーション プール: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

  3. ディレクトリに移動し、次のコマンドを入力して、Enter キーを押します。

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

  アプリケーション プールが ASP.NET 2.0 または 3.5 アプリケーション プールの場合は、次の手順を実行します。

  1. 管理コマンド プロンプトを開きます。

  2. アプリケーション プールが 32 ビットか 64 ビットかに応じて、適切なディレクトリを見つけます。

     • 32 ビット アプリケーション プール: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
     • 64 ビット アプリケーション プール: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

  3. ディレクトリに移動し、次のコマンドを入力して、Enter キーを押します。

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

  たとえば、アプリケーション プールの名前が My App Pool である場合 (前の図のように)、次のコマンドを実行します。
   
  aspnet_regiis -ga "IIS APPPOOL\My App Pool"

  注: aspnet_regiis ユーティリティが IIS APPPOOL\* 名を適切に解決するには、システム サービス APPHOSTSVC および WAS が実行されている必要がある場合があります。

• 解決策 2b: 明示的な <machineKey> 要素を作成する

  明示的な <machineKey> 要素をアプリケーションの Web.config ファイルに追加することで、開発者は自動生成された暗号化キーを使用しないように ASP.NET に指示します。 <machineKey> 要素を生成する方法については、付録 A を参照してください。

原因 3: LoadUserProfile=false を使用してアプリケーション プールが構成されている

アプリケーション プールがカスタム ID で実行されている場合は、IIS が ID のユーザー プロファイルを読み込んでいない可能性があります。 これには、HKCU レジストリが ASP.NET で自動生成された <machineKey> を保存できないという副作用があります。 そのため、アプリケーションを再起動するたびに、新しい自動生成キーが作成されます。 詳細については、Microsoft Web サイトの ユーザー プロファイル セクションを参照してください。

• 解決策 3a: aspnet_regiis ユーティリティを使用する

  これに関する手順は 、解決策 2a と同じです。 詳細については、そのセクションを参照してください。

• 解決策 3b: 明示的な <machineKey を使用する>

  明示的な <machineKey> 要素をアプリケーションの Web.config ファイルに追加することで、開発者は自動生成された暗号化キーを使用しないように ASP.NET に指示します。 <machineKey> 要素を生成する方法については、付録 A を参照してください。

• 解決策 3c: 必要な HKCU レジストリ キーを手動でプロビジョニングする

  aspnet_regiis ユーティリティを実行できない場合は、Windows PowerShell スクリプトを使用して HKCU の適切なレジストリ キーをプロビジョニングできます。 詳細については、 付録 B を参照してください。

• 解決策 3d: このアプリケーション プールに LoadUserProfile=true を設定します

  このアプリケーション プール内でのユーザー プロファイルの読み込みを有効にすることもできます。 これにより、HKCU レジストリ ハイブ、一時フォルダー、およびその他のユーザー固有の保存場所をアプリケーションで使用できるようになります。 ただし、これによりワーカー プロセスのディスクまたはメモリ使用量が増加する可能性があります。 この設定を有効にする方法の詳細については、 要素 を参照してください。

原因 4: Page.ViewStateUserKey プロパティの値が正しくない

ソフトウェア開発者は、Page.ViewStateUserKey プロパティを使用して、クロスサイト リクエスト フォージェリ保護を__VIEWSTATEフィールドに追加することができます。 Page.ViewStateUserKey プロパティを使用する場合、通常は現在のユーザーのユーザー名やユーザーのセッション識別子などの値に設定されます。 Microsoft Visual Studio 2012 以降のバージョンの WebForms アプリケーション用のプロジェクト テンプレートには、このプロパティを使用するサンプルが含まれています。 詳細については、Microsoft Developer Network (MSDN) Web サイトの Page.ViewStateUserKey プロパティ のトピックを参照してください。

ViewStateUserKey プロパティが指定されている場合、その値は生成時に __VIEWSTATE に書き込まれます。 __VIEWSTATE フィールドが使用されると、サーバーは現在のページの ViewStateUserKey プロパティをチェックし、__VIEWSTATE フィールドの生成に使用された値に対して検証します。 値が一致しない場合、要求は悪意がある可能性があるため拒否されます。

ViewStateUserKey 関連のエラーの例としては、ブラウザーで 2 つのタブが開いているクライアントが挙げられます。 クライアントはユーザー A としてログインしており、最初のタブで、ViewStateUserKey プロパティに「ユーザー A」が含まれている__VIEWSTATEでページがレンダリングされます。2 番目のタブで、クライアントはログアウトしてから、ユーザー B として再度ログインします。クライアントは最初のタブに戻り、フォームを送信します。 ViewStateUserKey プロパティに「ユーザー B」が含まれている場合があります (クライアントの認証 Cookie でそう言われているため)。 ただし、クライアントが送信した__VIEWSTATEフィールドには「ユーザー A」が含まれています。この不一致が失敗の原因となります。

• 解決策 4a: ViewStateUserKey が正しく設定されていることを確認する

  アプリケーションで ViewStateUserKey プロパティを使用する場合は、ビュー ステートが生成されるときと使用されるときの両方で、プロパティの値が同じであることを確認します。 現在ログインしているユーザーのユーザー名を使用している場合は、そのユーザーがまだログインしていること、およびポストバック時にユーザーの ID が変更されていないことを確認します。 現在のユーザーのセッション識別子を使用している場合は、セッションがタイムアウトしていないことを確認してください。

  ファーム環境で実行している場合は、 <machineKey> 要素が一致していることを確認します。 これらの要素を生成する方法については、 付録 A を参照してください。

          

付録 A: <machineKey> 要素を生成する方法

        
<machineKey> 要素を自分で生成するには、次の Windows PowerShell スクリプトを使用できます。

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

ASP.NET 4.0 アプリケーションでは、パラメーターなしで Generate-MachineKey を呼び出すだけで、次のように <machineKey> 要素を生成できます。

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

ASP.NET 2.0 および 3.5 アプリケーションは HMACSHA256 をサポートしていません。 代わりに、SHA1 を指定して、次のように互換性のある <machineKey> 要素を生成できます。

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

<machineKey> 要素がある場合は、それを Web.config ファイルに配置できます。 <machineKey> 要素は、アプリケーションのルートにある Web.config ファイルでのみ有効で、サブフォルダー レベルでは無効です。

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

サポートされているアルゴリズムの完全な一覧については、Windows PowerShell プロンプトからヘルプ Generate-MachineKey を実行してください。

付録 B: 自動生成キーを保持するためのレジストリのプロビジョニング

既定では、ASP.NET の自動生成キーは HKCU レジストリに保持されます。ユーザー プロファイルが IIS ワーカー プロセスに読み込まれておらず、アプリケーション プールがリサイクルされた場合、これらのキーは失われる可能性があります。 このシナリオは、アプリケーション プールを標準の Windows ユーザー アカウントとして実行している共有ホスティング プロバイダーに影響を与える可能性があります。

この状況を回避するために、ASP.NET では、HKCU レジストリではなく HKLM レジストリに自動生成されたキーを保持できます。 これは通常、aspnet_regiis ユーティリティを使用して実行されます (「解決策 2a: aspnet_regiis ユーティリティを使用する」セクションの手順を参照してください)。 ただし、このユーティリティを実行したくない管理者の場合は、代わりに次の Windows PowerShell スクリプトを使用できます。

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

次の例は、ユーザー example@contoso.com (これは Windows ユーザー アカウントの UPN です) として実行されるアプリケーション プールに対して、適切な HKLM レジストリ エントリをプロビジョニングする方法を示しています。 このアプリケーション プールは、CLR v2.0 (ASP.NET 2.0 または 3.5) を実行する 32 ビット アプリケーション プールです。

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

代わりに、アプリケーション プールが CLR v4.0 (ASP.NET 4.0 または 4.5) を実行している 64 ビット アプリケーション プールである場合、コマンドは次のようになります。

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

自動生成されたキーは HKLM に保存されますが、各ユーザー アカウントの秘密の暗号化マテリアルを保持するレジストリ サブキーは、アクセス制御リスト (ACL) に追加されるため、他のユーザー アカウントが暗号化マテリアルを読み取ることができなくなります。

付録 C: 構成ファイル内の <machineKey> 要素の暗号化

サーバー管理者は、構成ファイルで <machineKey> キー マテリアルなどの機密度の高い情報をプレーンテキスト形式にしたくない場合があります。 この場合、管理者は "保護された構成" として知られる .NET Framework 機能を利用することに決定することがあります。この機能を使用すると、.config ファイルの特定のセクションを暗号化できます。 これらの構成ファイルの内容が公開された場合でも、これらのセクションの内容は秘密のままです。

保護された構成の概要については、MSDN Web サイトを参照してください。 また、Web.config ファイルの <connectionStrings> 要素と <machineKey> 要素を保護する方法に関するチュートリアルも含まれています。