問題タブ [machinekey]

別の問題をデバッグするために、ViewStateなどの暗号化/復号化に使用されている現在のmachineKeyを取得しようとしています。（私のアプリはサーバーファームにあり、各サーバーとアプリケーションのmachine.configとweb.configにマシンキーが設定されているため、一部のリソースが適切に復号化されていない問題をデバッグしようとしています。実験中です。これにより、暗号化に使用されているものを確認できます。）コードスニペットは次のとおりです。

現状では、3行目は「オブジェクトのインスタンスに設定されていないオブジェクト参照」をスローしています。これは、おそらく2番目のnullパラメータを正しく設定していないことを意味します（プロパティにはインデックスを付ける必要がありますよね？）。

ただし、machineKeyのValidationKeyプロパティのParameterInfoは、長さがゼロで返されます（したがって、プロパティはインデックス付けされませんよね？）。

http://msdn.microsoft.com/en-us/library/b05d59ty(v=VS.90).aspx

私がここで見落としていることが明らかにあり、これを見るのに2番目の目が欲しいです。助言がありますか？

誰かがこのエラーを手伝ってくれませんか。通常、アプリケーションがアイドル状態のとき、またはセッションの有効期限が切れたときに発生します。

ありがとうございました

最近、製品のログにこのエラーが頻繁に表示されます。このエラーについてネットで検索しました。私はこれ、これ、またはこれのようなメモを見ました。それらすべての結論は、machineKey を設定する必要があるということです。しかし、すでに machineKey が設定されています。そのように：

また、私は Web ファーム サーバーを使用しており、アプリケーションは asp.net 3.5 を使用しています。

この問題についてどうしようもありません =\ どうすればこの問題を解決できますか?

ありがとう。

編集：

完全なログは次のとおりです。

IIS6でホストされている ASP.NET 3.5 Web サイトのセキュリティ対策として、常にビューステート暗号化を有効にしようとしています。ビューステートをオフにしましたが、この文字列にはまだ「controlstate」が表示されています。テスト環境では、web.config で以下を設定するだけで、ビューステートを base64 でデコードして半プレーンテキストにすることはできなくなりました。

<pages enableViewState="false" enableViewStateMac="true" viewStateEncryptionMode="Always">

次のコード (マシン キー ジェネレーターによって生成) を machine.config に追加しましたが、テスト サーバーでビューステートを正常に暗号化しています。

<machineKey validationKey="002..." decryptionKey="D90E..." validation="SHA1" decryption="AES" />

私の非テスト環境は、上記の設定で常にビューステートをプレーンテキストに base64 デコードできるため、上記の変更を反映していないようです。変更を加えた後は常にiisresetします。

私の非テスト Web サーバーに関する情報:

• Web ファーム/負荷分散 (ただし、現在テスト用に使用できるサーバーは 1 つだけです)
• Sql セッション状態 (これを設定するには、machine.config の machinekey が最初に必要でした)
• machine.config: 展開の小売 = "true"

asp.net ビューステートの暗号化を妨げる可能性のある追加の設定を探す場所を誰か提案できますか?

編集:現在、私のiisテストサーバーでは、viewStateEncryptionMode設定を「Never」に設定してもビューステートを暗号化しているため、設定を元に戻すことはできず、他のWebサイトはこの設定を保持していないようです。このプロパティがオーバーライドされている場所をどこで確認できますか? iisreset/stop www service/touch machine.config のときに実行されること以外に、クリアする必要があるこの設定が保存されているキャッシュはありますか?

EDIT FINAL：設定ファイルを何日も勉強した後、私はあきらめて、コードを介してこれを実装しました。ページ イベントにアタッチするセキュリティ モジュールを既に持っていたので、Page_Load に追加しました: Page.RegisterRequiresViewStateEncryption();

この設定がすぐに IIS6 に反映されない理由を知りたいです。ページノードを介してviewStateEncryptionModeを「Always」に設定すると、cassiniをローカルで実行すると、ビューステートがエンコードされ、id="__VIEWSTATEENCRYPTED"で追加の隠しフィールドがレンダリングされることがすぐにわかります。次に「Never」に設定すると、すぐに暗号化がオフになります。IIS6 でホストされている Web サイトの Web サイトにまったく同じ変更を加えても、すぐには効果がありませんが、設定をそのままにしておくと、最終的には有効になります。www サービスを停止/開始し、iis をリセットし、ASPNET 一時キャッシュをクリアしますが、実行しません。他に何を試すべきかわかりませんか？願わくば、この投稿がしばらくの間 ROT になり、将来誰かが私が経験したのと同じ動作を見て、これをさらに理解できるようになることを願っています!

.NET MVC アプリケーションを GoDaddy サーバーにデプロイしようとしています。ページの 1 つに Html.AntiForgeryToken があり、ヒットするたびに例外がスローされます。

次の URL を使用してマシン キーを生成しました

ページのviewStateEncryptionModeを「Always」に設定しました

ただし、まだエラーが発生しており、次に何をすべきか途方に暮れています。どんな提案でも大歓迎です。

既定では、マシン キーの設定は自動生成で、アプリケーションごと (AutoGenerate、IsolateApps) です。MSDN は、復号化キーと検証キーは Web アプリケーション ID に基づいていると述べています。IIS 7 サーバーで 2 つの ASP.NET MVC 2 サイトをホストしていますが、マシン キーが同じであることがわかりました。これを確認するには、リフレクションを使用して ValidationKeyInternal および DecryptionKeyInternal プロパティを確認しました。また、一方のサイトで偽造防止トークン Cookie を生成してテストし、それをもう一方のサイトに渡すと、Cookie を読み取ることができます。

試行錯誤の結果、アプリケーション プール ID が変更されるとキーが変更されることがわかりました。2 つのサイトは、ネットワーク サービス資格情報で実行されているため、同じキーを持っています。1 つのサイトのアプリケーション プール ID を変更すると、異なる検証/暗号化キーが使用されるようになります。

ただし、2 つのサイトを別のサーバーに展開した後は、アプリケーション プール ID を変更した後でも、常に同じマシン キーを取得します。2 台のサーバーのハードウェアとソフトウェアの構成は同じです。

AutoGenerate,IsolateApps 設定でマシン キーがどのように生成されるかの実際のロジックの参照があるかどうかを知りたいです。Web では、Web ファームのシナリオで同じマシン キーを設定することについて話している記事がたくさんあります。しかし、反対側で問題が発生しました。Web アプリケーションごとの自動キー生成が正しく機能していないようです。以前に同じ問題を抱えている人はいますか？

正確に言えば、SharePoint 2010ソリューションに変更を加えると、Visual Studioによってweb.configが更新され、要素が変更されます。

ログインを防ぎます。私が指定するキーでなければなりません。

ヘルプ！

私たちの実稼働環境には、負荷分散された 3 つのサーバーがあります。各サーバーには、IIS に 9 つのサイトがあります。各サイトには、1 ～ 15 個の異なるアプリがあります。

3 つのサーバーすべてで適切な暗号化/復号化を維持するには、対応するアプリに同じ validationKey と decryptionKey を使用する必要があります。これは、次の 3 つのレベルで設定できます。 - machine.config のサーバー レベル - web.config のサイト レベル - web.config のアプリ レベル

各レベルで設定することには明らかに長所と短所がありますが、サーバー対サイト対アプリでそれを行う具体的な理由を誰かが与えることができるかどうか疑問に思っていました.

machineKey Web ファームの展​​開に関する考慮事項セクションに、宣伝文があります。

アプリケーションを同じサーバー上の他のアプリケーションから分離する場合は、ファーム内の各サーバーの各アプリケーションの Web.config ファイルに を配置します。

validationKey は、3 つのサーバーにまたがる最大 100 の異なるアプリで異なるキーを使用することを正当化するのに十分な脅威ベクトルですか? 分かってる。どのくらいのリスクを冒しても構わないと思っていますか? 私はどの業界にいますか？自分のデータで誰かに何をしてもらいたいですか? 等

もちろん、最終的には、新しいサイトやアプリが追加されたときに基盤全体を確実にカバーするために、3 つのレベルすべてに配置することになると思います。しかし、私は回帰テストの取り組みをあまり楽しみにしていません。

ありがとう、マット

MSDN : マシン キー

フォーム認証データとビューステート データの暗号化、復号化、検証、およびアウトプロセス セッション状態の識別に使用するアルゴリズムとキーを構成します。

具体的には、FormsAuthentication のどのメソッドが validationKey と encryptionKey の値を利用しますか?

Web アプリに C# を使用して、データベース内のいくつかのフィールドを安全に暗号化する方法を見つけようとしています。

暗号化/復号化を行うスクリプトと、キーを保存する方法を見つける必要があります。マシンキーをキーとして使用できると読みましたが、それは正しいですか?

自動生成されたマシンキーと自動生成されていないマシンキーがあります。自動生成されていない方がいいと思います。このようにすると、Web アプリをさまざまなサーバーに簡単にデプロイできるからです。私はあなたのためにそれを生成するこのツールを見つけました：

http://aspnetresources.com/tools/machineKey

このマシンキーで機能する暗号化/復号化スクリプトはどれですか?

また、自動生成されていないマシン キーを web.config ファイルに保存するのはどの程度安全なのでしょうか? 誰かが web.config ファイルを見ることができる場合、たとえば appSettings で「通常の」キーの代わりに machinekey を使用するのはなぜですか?