我正在尝试始终打开视图状态加密，作为 IIS6 中托管的 ASP.NET 3.5 网站的安全措施。我们已关闭视图状态，但仍在此字符串中看到一些“控制状态”。在测试环境中，我可以简单地在 web.config 中设置以下内容，并且无法再将视图状态进行 Base64 解码为半明文：
我什至添加了以下内容（由 机器密钥生成生成器）到 machine.config 并仍然在我的测试服务器上对视图状态进行良好加密：
我的非测试环境似乎没有接受上述更改，因为我始终可以使用上述设置将视图状态进行 Base64 解码为纯文本。我总是在进行任何更改后重置。
关于我的非测试网络服务器的一些信息：
- 网络场/负载平衡（但现在只有一台服务器用于测试）
- Sql 会话状态（最初需要 machine.config 中的 machinekey 来设置它）
- machine.config：部署零售= true”
任何人都可以建议在哪里寻找可能干扰 ASP.NET 视图状态加密的其他设置吗？
编辑：现在在我的 iis 测试服务器上，我无法撤消 viewStateEncryptionMode 设置，因为它正在加密视图状态，即使我将其设置为“从不”，而且我的其他网站似乎都没有保留此设置。我可以在哪里查看该属性被覆盖的位置？除了 iisreset/stop www service/touch machine.config 时执行的操作之外，是否还有存储此设置的缓存需要清除？
编辑最终：经过几天的研究配置文件后，我放弃并通过代码实现了这一点。我已经有一个附加到页面事件的安全模块，因此在 Page_Load 中我添加了： Page.RegisterRequiresViewStateEncryption();
我真的很想知道是什么阻止了 IIS6 立即采用此设置。当我在本地运行 cassini 时，如果我通过页面节点将 viewStateEncryptionMode 设置为“Always”，我会立即看到它对视图状态进行编码并使用 id="__VIEWSTATEENCRYPTED" 渲染附加隐藏字段。当我将其设置为“从不”时，我会立即看到加密关闭。如果我对 IIS6 托管网站上的网站进行同样的更改，它不会立即生效，但如果我允许设置保留在那里，它最终会生效。我会停止/启动 www 服务，重置 iis，清除 ASPNET 临时缓存，但我不知道还能尝试什么？希望这篇文章可以烂掉一段时间，将来有人会看到我经历过的相同行为，我们可以进一步弄清楚这一点！
I am attempting to turn on viewstate encryption Always as a security measure for my ASP.NET 3.5 website hosted in IIS6. We have viewstate turned off but still see some "controlstate" in this string. In a test environment I am able to simply set the following in web.config and i can no longer base64 decode the viewstate to semi-plaintext:
<pages enableViewState="false" enableViewStateMac="true" viewStateEncryptionMode="Always">
I have even added the following (genereated by machine key generater) to machine.config and still encrypts the viewstate fine on my test server:
<machineKey validationKey="002..." decryptionKey="D90E..." validation="SHA1" decryption="AES" />
My non-test environment doesn't seem to pick up the above changes as i can always base64 decode the viewstate to plain text with the above settings. I always iisreset after i make any changes.
Some info about my non-test webserver:
- Web Farm/Load Balanced (but only one server up for testing right now)
- Sql Session State (machinekey in machine.config was initially needed to set this up)
- machine.config: deployment retail="true"
Can anyone suggest where to look for additional settings that might interfere with asp.net viewstate encryption?
EDIT: Now on my iis test server i cannot undo the viewStateEncryptionMode setting as it is encrypting the viewstate even when i set it to "Never" and none of my other websites seem to take a hold of this setting. Where can i possibly look to see where this property is being overridden? Is there any cache where this setting is stored that needs to be cleared besides what would be done when i iisreset/stop www service/touch machine.config?
EDIT FINAL: After days of studying config files i gave up and implemented this via code. I already had a security module that was attaching to page events so in Page_Load i added: Page.RegisterRequiresViewStateEncryption();
I would really love to know what was preventing this setting from getting picked up on IIS6 immediatley. When i run cassini locally if i set the viewStateEncryptionMode to "Always" via the pages node i would immediately see it encode the viewstate and render the additional hidden field with id="__VIEWSTATEENCRYPTED". When i then set it to "Never" i would immediately see the encryption turn off. If i make the same exact change to the website on my IIS6 hosted website, it would have no effect immediately but if i allow the setting to stay there it would eventually take hold. I would stop/start www service, reset iis, clear ASPNET temp cache but i don't know what else to try? Hopefully this post can ROT for a while and someone in the future will see the same behavior i experienced and we can further figure this out!
发布评论
评论（3）
我的猜测是负载平衡网络场是混乱的根源。您表示“现在只有一台服务器可供测试”，但您遇到的所有症状听起来与网络场中的多台服务器正在运行时所发生的情况完全相同，但您只做了 web.config以及一台服务器上的 machine.config 更改。当您使用浏览器访问网站时，有时您会访问以一种方式配置的一台服务器，有时您会访问以另一种方式配置的另一台服务器。
My guess is the that load balanced web farm is the source of the confusion. You stated that only "only one server [is] up for testing right now", but all the symptoms you're experiencing sound exactly like what would happen if multiple servers in the web farm were running, but you only made the web.config and machine.config changes on one server. When you hit the website with your browser, sometimes you would hit one server that was configured one way, sometimes you would hit another server that was configured another way.
我知道您发布此文章已经有一段时间了，但是您是否考虑过自己实现 PageStatePersister？ PageStatePersister 是负责格式化页面中嵌入的 ViewState 和 ControlState 数据的组件。如果安全性是您最关心的问题，您可以使用任何您想要的加密算法来确保您的数据保持私密性。根据您的配置，听起来您处于一个功能相当强大的环境中，因此显然首先要进行负载测试。还值得一提的是，当合并到“经典”ASP.NET WebForms 站点中时，我对 MVC 在 ViewState 中的分层参与一无所知或没有经验。
祝你好运。
乙
I know it's been a while since you posted this, but have you considered making your own implementation of PageStatePersister? PageStatePersister is the component responsible for formatting the ViewState and ControlState data embedded in your page. If security is your primary concern you can use whatever encryption algorithms you'd like to ensure your data remains private. Based on your configuration it sounds like you're in a rather capable environment, so obviously load-test first. It's also worth mentioning that I have no idea regarding or experience with MVC's layered involvement in ViewState when incorporated in a "classic" ASP.NET WebForms site.
Good luck.
B
Web.config 页面设置不适用于禁用可更新选项的预编译 ASP.Net 应用程序。 已经有一段时间了，但我可能已经部署了测试服务器禁用可更新选项...吸取教训。
请参阅 MSDN
类似 我问的问题，相同 问题。
Web.config page settings do not apply to pre-compiled ASP.Net application with updatable option disabled. It has been a while but my test server i likely had deployed with updatable option disabled ... lesson learned.
SEE MSDN
Similar Question i Asked, same issue.