防止CSRF攻击

防止CSRF攻击

跨站点请求伪造（Cross-Site Request Forgery，简称CSRF）是一种常见的网络攻击类型。当用户在受信任的站点上通过身份验证后，访问攻击者精心准备的恶意网站、电子邮件、博客、即时消息或程序时，可能会导致用户的网页浏览器在受信任站点上执行未预期的操作（如创建、修改或删除操作）。CSRF攻击之所以有效，是因为浏览器请求会自动包含所有cookie，包括会话cookie。因此，如果用户已经在该站点上通过身份验证，服务器就无法区分合法的授权请求和伪造的请求。通过适当的授权机制可以阻止此类攻击，这意味着需要使用挑战-响应机制来验证请求者的身份和权限。

CSRF攻击的工作原理

CSRF攻击利用了用户在受信任站点上已经通过身份验证这一事实。以下是CSRF攻击的一般工作原理：

1. 用户登录受信任站点：用户通过用户名和密码在受信任的站点上登录，并获得一个有效的会话cookie。
2. 用户访问恶意站点：用户在浏览器中打开另一个标签页或窗口，访问一个恶意站点。恶意站点上包含了一些恶意代码，例如一个隐藏的表单或自动提交的脚本。
3. 恶意请求发送到受信任站点：恶意站点利用用户的会话cookie，向受信任站点发送一个未经授权的请求。这些请求会被受信任站点视为合法请求，因为它们携带了有效的会话cookie。
4. 受信任站点执行恶意请求：由于受信任站点无法区分这是用户的真实请求还是恶意请求，因此会执行这些操作。

实施保护机制防止CSRF攻击

1. 确认并使用框架内置的 CSRF 防御技术

许多现代Web框架都已经内置了CSRF防御机制。例如，ASP.NET、Django、Ruby on Rails等框架都提供了内置的CSRF防护。在使用这些框架时，确保启用了这些内置保护功能是防止CSRF攻击的第一步。

ASP.NET的CSRF防护示例：

在ASP.NET中，可以通过使用[ValidateAntiForgeryToken]属性来启用CSRF防护：

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Transfer(TransferModel model)
{
    // 处理转账操作
}

2. 在执行创建、修改或删除操作时使用同步器令牌模式

同步器令牌模式（Synchronizer Token Pattern）是一种有效的防止CSRF攻击的方法。这种模式要求每次请求都携带一个唯一的令牌，并在服务器端进行验证。

3. CSRF 令牌的生成和验证

CSRF令牌应在服务器端生成，并针对每个用户会话或每个请求（创建、修改或删除操作）生成。当客户端发出请求时，服务器端组件必须验证请求中的令牌是否存在以及其有效性，与用户会话中的令牌进行比对。如果在请求中未找到令牌，或者提供的值与用户会话中的值不匹配，则应中止请求并记录为潜在的CSRF攻击。

CSRF令牌的特点

CSRF令牌应该满足以下条件：

• 唯一性：对于每个用户会话，令牌应是唯一的。
• 保密性：令牌应是保密的，不能被外界轻易猜测。
• 不可预测性：令牌应不可预测，应由安全方法生成的大随机值。

例如：

<form action="/transfer.do" method="post">
    <input type="hidden" name="CSRFToken" value="OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZMGYwMGEwOA==">
    [...]
</form>

在服务器端，需要对令牌进行验证：

String csrfToken = request.getParameter("CSRFToken");
if (csrfToken == null || !csrfToken.equals(session.getAttribute("CSRFToken"))) {
    throw new SecurityException("CSRF token mismatch");
}

4. 对高度敏感的操作实施基于用户交互的保护

对于高度敏感的操作，可以实施基于用户交互的保护措施，例如使用CAPTCHA、验证密码或双因素身份验证（2FA）等。这些额外的步骤可以增加攻击者进行CSRF攻击的难度。

使用CAPTCHA防护：

<form action="/sensitiveAction" method="post">
    <!-- 其他表单字段 -->
    <div class="g-recaptcha" data-sitekey="your-site-key"></div>
    <input type="submit" value="Submit">
</form>
<script src="https://www.google.com/recaptcha/api.js" async defer></script>

5. 使用自定义请求头

考虑使用自定义请求头来增加请求的安全性。通过添加自定义请求头，可以确保请求来自预期的客户端，而不是恶意网站。例如，可以在Ajax请求中添加一个自定义头：

$.ajax({
    type: "POST",
    url: "/sensitiveAction",
    headers: {
        "X-CSRF-Token": csrfToken
    },
    data: {
        // 其他数据
    }
});

在服务器端，需要对自定义头进行验证：

String csrfToken = request.getHeader("X-CSRF-Token");
if (csrfToken == null || !csrfToken.equals(session.getAttribute("CSRFToken"))) {
    throw new SecurityException("CSRF token mismatch");
}

6. 验证请求头的来源

验证请求头的Referer或Origin字段可以进一步增强安全性。这可以确保请求确实来自合法的来源，而不是恶意网站。例如：

String referer = request.getHeader("Referer");
if (referer == null || !referer.startsWith("http://domain.com")) {
    throw new SecurityException("Invalid referer");
}

参考链接

• OWASP CSRF
• OWASP CSRF Prevention Cheat Sheet
• ASP.NET CSRF 防护
• Django CSRF 防护
• Ruby on Rails CSRF 防护