CSRF攻击原理与解决方法-CSDN博客

本文链接：https://blog.csdn.net/a_beiyo/article/details/147444101

什么是CSRF攻击？

跨站请求伪造（Cross-Site Request Forgery，简称CSRF）是一种常见的网络攻击方式，攻击者通过诱导用户在已认证的网站上执行非预期的操作，从而实现恶意目的。CSRF攻击利用了用户在目标网站上的有效会话，通常无需用户直接参与即可完成攻击。

例如，用户登录了银行网站并保持会话有效，攻击者通过诱导用户点击恶意链接或访问伪造页面，触发对银行网站的请求（如转账操作），而浏览器会自动附带用户的有效Cookie，导致请求被网站误认为是合法操作。

CSRF攻击的工作原理

CSRF攻击的核心在于利用浏览器的自动Cookie发送机制。以下是CSRF攻击的典型流程：

用户登录目标网站：用户登录银行网站，浏览器保存了会话Cookie，证明用户身份。
攻击者构造恶意请求：攻击者创建一个伪造页面，包含触发目标网站操作的请求（如转账到攻击者账户）。
诱导用户访问：攻击者通过钓鱼邮件、恶意链接或嵌入式内容（如图片、表单）诱导用户访问伪造页面。
浏览器发送请求：用户访问伪造页面时，浏览器自动发送请求到目标网站，并附带用户的会话Cookie。
网站执行操作：目标网站因无法区分请求来源，误认为请求来自合法用户，执行相应操作。

攻击的关键点在于：

用户在目标网站有有效的会话。
浏览器会自动附带Cookie。
攻击者无需窃取Cookie，只需诱导用户触发请求。

CSRF攻击的危害

CSRF攻击可能导致以下严重后果：

财务损失：如未经授权的银行转账。
数据篡改：修改用户账户信息（如邮箱、密码）。
隐私泄露：泄露用户敏感数据。
功能滥用：执行用户权限范围内的任何操作，如发布内容、删除数据等。

CSRF攻击的常见形式

GET型CSRF：攻击者通过构造一个GET请求（如<img src="http://bank.com/transfer?to=attacker&amount=1000">）诱导用户访问，浏览器加载图片时自动发送请求。
POST型CSRF：攻击者通过伪造表单（如隐藏的<form>）和自动提交脚本，诱导用户提交POST请求。
链接型CSRF：攻击者通过钓鱼邮件或社交工程诱导用户点击恶意链接，触发请求。

如何防御CSRF攻击？

防御CSRF攻击需要从服务器和客户端两方面入手，以下是常见的防御措施：

1. 使用CSRF令牌（Token）

原理：在每个表单或请求中添加一个随机生成的CSRF令牌，服务器验证令牌是否有效。
实现：
- 服务端为每个会话生成唯一的CSRF令牌。
- 表单提交时，客户端必须附带此令牌。
- 服务端验证令牌是否匹配，拒绝不合法的请求。
优点：令牌是动态的，攻击者难以伪造。
注意：令牌需绑定到用户会话，避免被复用。

2. 验证HTTP Referer头

原理：检查请求的Referer头，确保请求来源是可信的域名。
局限性：
- Referer可能被浏览器或代理隐藏。
- 攻击者可能伪造Referer（较少见）。
建议：作为辅助防御手段，不宜单独依赖。

3. 使用SameSite Cookie属性

原理：设置Cookie的SameSite属性，限制跨站请求携带Cookie。
选项：
- Strict：仅允许同站请求携带Cookie。
- Lax：允许部分跨站GET请求（如导航链接）携带Cookie。
- None：无限制，需配合Secure属性。
优点：现代浏览器广泛支持，配置简单。
注意：需确保网站使用HTTPS。

4. 验证请求方法

原理：限制敏感操作仅接受POST请求，拒绝GET请求。
局限性：POST请求仍可能被CSRF攻击伪造。
建议：结合CSRF令牌使用。

5. 要求二次验证

原理：对敏感操作（如转账、修改密码）要求用户重新输入密码或进行其他身份验证。
优点：即使CSRF攻击成功，操作也无法完成。
局限性：可能影响用户体验。

6. 用户教育与客户端防护

用户端：
- 及时登出敏感网站。
- 避免点击不明链接或访问可疑网站。
客户端防护：
- 浏览器插件（如uBlock Origin）可阻止恶意请求。
- 禁用自动加载图片或脚本。

CSRF与XSS的区别

CSRF常与跨站脚本攻击（XSS）混淆，但两者有本质区别：

CSRF：
- 利用用户对目标网站的信任。
- 不需窃取用户数据，仅触发操作。
- 依赖有效会话和浏览器自动发送Cookie。
XSS：
- 利用网站对用户输入的信任。
- 注入恶意脚本，窃取数据或控制用户浏览器。
- 更直接，危害范围更广。

实际案例分析

案例1：某银行网站CSRF漏洞

某银行网站允许通过GET请求执行转账操作，攻击者通过构造恶意链接（如http://bank.com/transfer?to=attacker&amount=1000）诱导用户点击，导致资金被转移。教训：敏感操作应使用POST请求并结合CSRF令牌。

案例2：社交平台CSRF攻击

攻击者在社交平台上发布包含自动提交表单的帖子，用户访问帖子时自动触发关注或发布内容的请求。教训：使用SameSite Cookie和CSRF令牌可有效阻止此类攻击。

使用 Spring Security 的 Java 示例：

Spring Security 是一种流行的 Java 安全框架，它提供了内置的 CSRF 保护，您应该利用它。

配置（Spring Security）：

默认情况下，Spring Security 启用 CSRF 保护。你可能需要确保安全配置中未明确禁用该保护：

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            // Other security configurations...
            .csrf(); // Enables CSRF protection (default)
        return http.build();
    }
}

在表单中集成 CSRF 令牌（Thymeleaf 示例）：

如果您使用像 Thymeleaf 这样的模板引擎，Spring Security 会自动提供一种机制将 CSRF 令牌包含在您的表单中：

<form action="/transfer" method="post">
    <input type="hidden" th:name="${_csrf.parameterName}" th:value="${_csrf.token}" />
    <label for="amount">Amount:</label>
    <input type="text" id="amount" name="amount" /><br />
    <label for="recipient">Recipient:</label>
    <input type="text" id="recipient" name="recipient" /><br />
    <button type="submit">Transfer</button>
</form>

这里，_csrf.parameterName和_csrf.token是 Spring Security 提供的 Thymeleaf 变量，自动将 CSRF 令牌作为隐藏字段注入。

在 AJAX 请求中处理 CSRF 令牌（Java 后端）：

对于 AJAX 请求，通常需要在自定义 HTTP 标头中发送 CSRF 令牌。Spring Security 默认将令牌放置在X-XSRF-TOKEN指定的标头中。

在后端，Spring Security 的 CSRF 过滤器会自动检查此标头。如果您启用了 CSRF 保护，通常无需编写显式的 Java 代码来处理验证。

前端防御（Vue.js 示例）

在 Vue.js 前端，您需要检索 CSRF 令牌（通常由后端在初始 HTML 中或通过 API 端点提供）并将其包含在状态更改请求中。

场景 1：初始 HTML 中的 CSRF 令牌：

如果您的后端使用 CSRF 令牌（例如，在<meta>标签中）呈现初始 HTML，则您的 Vue.js 应用程序可以读取它：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="csrf-token" content="${_csrf.token}">
    </head>
<body>
    <div id="app">
        </div>
    <script src="/js/app.js"></script>
</body>
</html>

Vue.js 代码在 AJAX 请求中包含令牌（使用 Axios）：

import axios from 'axios';

const csrfToken = document.querySelector('meta[name="csrf-token"]').getAttribute('content');

// Set the CSRF token as a default header for all subsequent requests
if (csrfToken) {
  axios.defaults.headers.common['X-XSRF-TOKEN'] = csrfToken;
}

// Example of a state-changing request
axios.post('/api/transfer', { amount: 100, recipient: 'attacker' })
  .then(response => {
    console.log('Transfer successful:', response.data);
  })
  .catch(error => {
    console.error('Transfer failed:', error);
  });

场景 2：来自后端 API 端点的 CSRF 令牌：

或者，您的后端可能会提供专用的 API 端点，以在应用程序加载时获取 CSRF 令牌。

用于获取和包含令牌的 Vue.js 代码：

import axios from 'axios';

axios.get('/api/csrf-token')
  .then(response => {
    const csrfToken = response.data.token;
    axios.defaults.headers.common['X-XSRF-TOKEN'] = csrfToken;

    // Now you can make state-changing requests
    axios.post('/api/update-profile', { name: 'New Name' })
      .then(profileResponse => {
        console.log('Profile updated:', profileResponse.data);
      })
      .catch(profileError => {
        console.error('Profile update failed:', profileError);
      });
  })
  .catch(error => {
    console.error('Failed to fetch CSRF token:', error);
  });

前端的重要注意事项：

一致包含：确保 CSRF 令牌包含在所有状态更改请求（POST、PUT、DELETE、PATCH）中。
令牌传输的安全性：虽然 HTTP 标头通常是安全的，但请避免在 URL 中传输 CSRF 令牌，因为它可能会被记录或暴露。

其他防御机制（不太常见或补充）：

SameSite Cookie 属性：此属性指示浏览器不要在跨站请求中发送 Cookie。它提供了一层良好的防御，但由于浏览器兼容性以及可能无法完全阻止攻击（例如，通过 GET 请求或某些浏览器行为）的情况，它本身并非一个完整的解决方案。设置SameSite=Strict或SameSite=Lax可以显著降低 CSRF 风险。
双重提交 Cookie：此技术需要在 Cookie 和请求参数中分别设置一个随机值。服务器会验证这两个值是否存在且是否匹配。虽然它避免了服务器端会话存储令牌，但正确实现起来可能更加复杂。
源标头验证：服务器可以检查传入请求的Origin和Referer标头，以查看它们是否与预期域匹配。然而，在某些情况下，这些标头可能会被攻击者操纵，这使得这种防御措施本身的可靠性较低。