尽管在 Web.config 中设置了 X-Frame 选项，但抑制 global.asax 中的防伪 X-Frame 选项标头会削弱安全性？答案

【问题标题】：Suppressing anti-forgery X-Frame options header in the global.asax weakens security despite setting X-Frame options in Web.config?尽管在 Web.config 中设置了 X-Frame 选项，但抑制 global.asax 中的防伪 X-Frame 选项标头会削弱安全性？
【发布时间】：2017-06-06 10:40:52
【问题描述】：

我们的 MVC5 应用程序包含一个局部视图，该视图使用 Master.cshtml 在所有页面上呈现 Html.AntiForgeryToken。

在我们呈现另一个表单和另一个 Html.AntiForgeryToken 的页面上，在提交表单时会引发异常：

Server cannot append header after HTTP headers have been sent.

为了避免异常，我们可以在Global.asax App_Start 中指定：

AntiForgeryConfig.SuppressXFrameOptionsHeader = true;

我们担心的是，我们是否允许其他人将我们的网站作为 iFrame 嵌入，并启用“ClickJacking”？

无论我们是否也使用需要我们在 Web.config 中指定的 Umbraco 7.6.1，都会发生上述情况：

    <httpProtocol>
     <customHeaders>
      <remove name="X-Powered-By" />
      <add name="X-Frame-Options" value="SAMEORIGIN" />
     </customHeaders>
    </httpProtocol>

这种矛盾的配置有替代方案吗？我们是否正在削弱安全性？

【问题讨论】：

标签： asp.net-mvc asp.net-mvc-5 antiforgerytoken x-frame-options

【解决方案1】：

通过抑制 Html.AntiForgeryToken 中的 X-Frame-Options 标头，您可能会因承担应用 X-Frame-Options 标头的责任而削弱安全性。

在您的情况下，安全性没有被削弱，因为您使用 Web.config 来应用 X-Frame-Options 标头，其值与 Html.AntiForgeryToken 将应用的值相同。您的安全性实际上比 Html.AntiForgeryToken 提供的更强大，因为 X-Frame-Options 标头将应用于所有响应，包括您忽略或无法使用 Html.AntiForgeryToken 的表单。

【讨论】：