欢迎来到蓝队云技术小课堂，每天分享一个技术小知识。

跨站请求伪造（CSRF，Cross-Site Request Forgery）是一种网络攻击，攻击者通过欺骗用户的浏览器，伪造用户的请求并发送到受信任的网站，从而执行用户未授权的操作。为了防范 CSRF 攻击，特别是在 IIS（Internet Information Services）环境中部署的 Web 应用程序中，可以采取多种措施，确保 Web 应用的安全性。

下面是 IIS 环境下防范 CSRF 攻击的详细教程：

一、CSRF 攻击原理简述

CSRF 攻击的核心在于利用用户的身份验证状态，欺骗用户浏览器去执行未授权的操作，通常包括如下步骤：

用户登录到一个可信网站 A，并获得一个身份验证 Cookie。

用户在未登出 A 的情况下访问攻击者控制的恶意网站 B。

恶意网站 B 向网站 A 发送伪造的请求，借用用户的身份验证 Cookie，使 A 认为该请求是用户授权的。

这种攻击会造成严重的安全隐患，特别是在涉及财务交易、个人隐私和账户管理的操作中。

二、CSRF 的防范措施

要有效防范 CSRF 攻击，可以通过以下措施来加强 Web 应用在 IIS 上的安全性。

1. 使用 CSRF Token

核心思想：在每个敏感操作的请求中加入一个唯一的、难以预测的令牌（Token）。该令牌与用户会话绑定，并且只有用户可以通过页面提交合法请求时获得这个令牌，攻击者无法获取。

实现步骤：

每次生成一个包含 CSRF Token 的表单页面时，在表单中嵌入一个隐藏字段，令牌由服务器生成。

服务器验证每次提交时，必须确认请求中包含的 CSRF Token 是否与服务器存储的 Token 匹配。

ASP.NET 实现：

在 ASP.NET MVC 中，可以通过内置的 @Html.AntiForgeryToken() 方法生成 CSRF Token：

<form method="post" action="/SubmitData">

    @Html.AntiForgeryToken()

    <!-- 其他表单元素 -->

</form>

控制器中的相应动作使用 [ValidateAntiForgeryToken] 属性进行验证：

[HttpPost]

[ValidateAntiForgeryToken]

public ActionResult SubmitData(MyModel model)

{

    // 处理数据

}

注意事项：

所有需要保护的表单和 Ajax 请求都应包含 CSRF Token。

使用 HTTPS 加密传输，以防 Token 被窃取。

2. 限制请求方法

许多 CSRF 攻击利用浏览器自动发出的 GET 请求。为了防止 CSRF，应该将敏感操作限定为仅通过 POST、PUT、DELETE 等请求方法完成。

在 IIS 中，可以通过 Web 配置文件 (web.config) 来限制特定路径只允许特定的请求方法。例如：

<system.webServer>

    <security>

        <requestFiltering>

            <verbs>

                <add verb="GET" allowed="false" />

            </verbs>

        </requestFiltering>

    </security>

</system.webServer>

3. 使用 SameSite Cookie 属性

SameSite 属性用于指定 Cookie 在跨站请求中是否可以发送。通过设置 SameSite 属性为 Strict 或 Lax，可以有效防止 CSRF 攻击：

Strict：Cookie 在任何跨站请求中都不会发送。

Lax：Cookie 在某些跨站请求中（例如导航到链接）可以发送，但不包括表单提交和其他敏感操作。

设置 SameSite 属性：

在 IIS 的 ASP.NET 应用程序中，你可以在 web.config 中为身份验证 Cookie 设置 SameSite 属性：

<system.web>

    <authentication mode="Forms">

        <forms loginUrl="~/Account/Login" protection="All" timeout="30" slidingExpiration="true" cookieless="UseCookies" cookieSameSite="Strict" />

    </authentication>

</system.web>

4. 验证 HTTP Referer 或 Origin

CSRF 攻击中的请求通常不会来自受信任的站点。可以通过检查 HTTP 请求的 Referer 或 Origin 头来验证请求来源。

服务器只接受来自同一站点的请求：

Referer：通常会包含用户所在页面的 URL。

Origin：指示请求来源的主机名。

注意：检查 Referer 或 Origin 可以作为额外的防护措施，但不能作为唯一手段，因为有时浏览器可能不会发送这些头部，或者它们可以被伪造。

5. 双重 Cookie 验证

双重 Cookie 验证是一种 CSRF 防护策略，要求每个请求同时提供：

一个身份验证的会话 Cookie。

一个在页面中通过 JavaScript 读取的令牌，该令牌也由服务器生成并与会话绑定。

当用户发送请求时，服务器会同时验证 Cookie 和页面中的 Token。

6. 强制用户登录以进行敏感操作

确保敏感的操作仅在用户登录状态下才可以进行，并定期要求用户重新验证身份，例如输入密码或通过两步验证。

7. 启用 HTTPS

启用 HTTPS 以确保 Cookie 和 CSRF Token 在传输过程中不会被窃取或篡改。HTTP 中的明文传输会使得攻击者更容易进行中间人攻击，窃取用户会话信息。

三、在 IIS 中的配置

除了在代码级别防护 CSRF 攻击，你还可以在 IIS 中进一步增强安全性。

1. 启用请求验证

IIS 允许启用请求验证，阻止潜在危险的输入。你可以通过修改 web.config 来启用请求验证：

<system.web>

    <pages validateRequest="true" />

</system.web>

2. 配置 URL 重写

使用 IIS URL 重写模块，可以防止某些类型的跨站请求伪造。例如，禁止带有潜在 CSRF 攻击路径的请求。

四、总结

防范 CSRF 攻击需要结合多种防护措施，包括 CSRF Token、Cookie 安全设置、请求方法限制等。在 IIS 上运行的 Web 应用，应该启用这些安全措施以减少 CSRF 攻击的风险，同时确保 HTTPS 的使用，以保护传输中的敏感数据。

蓝队云官网上拥有完善的技术支持库可供参考，大家可自行查阅，更多技术问题，可以直接咨询。同时，蓝队云整理了运维必备的工具包免费分享给大家使用，需要的朋友可以直接咨询。

更多技术知识，蓝队云期待与你一起探索。