发布于 由admin

CSRF 攻击原理与防御：SameSite Cookie 属性与自定义 Header 的双重保障

各位技术同仁，下午好！

今天，我们齐聚一堂，探讨一个在Web安全领域经久不衰却又不断演进的话题：跨站请求伪造（CSRF）攻击。这并非一个新概念，但随着Web技术的发展和浏览器安全策略的更新，我们对抗CSRF的手段也在不断进步。特别是SameSite Cookie属性的普及和自定义Header的巧妙运用，为我们构建了一个更坚固的双重保障。

作为一名编程专家，我深知理论与实践的结合至关重要。因此，今天的讲座将不仅深入剖析CSRF的原理，更会通过大量的代码示例，手把手地向大家展示如何将这些先进的防御机制落地。

Web安全威胁的无声硝烟与CSRF的崛起

互联网的蓬勃发展，极大地便利了我们的生活。然而，这种便利也伴随着无处不在的安全威胁。从数据泄露到服务中断，从身份盗用再到金融欺诈，每一次成功的网络攻击都可能造成无法估量的损失。在众多Web安全漏洞中，跨站请求伪造（Cross-Site Request Forgery，简称CSRF）以其独特的隐蔽性和利用浏览器信任机制的特点，长期以来都是一个令人头疼的问题。

CSRF攻击的狡猾之处在于，它利用的是用户对某个网站的信任，以及浏览器在发送请求时自动携带Cookie的机制。攻击者并不需要直接窃取用户的凭证，也不需要绕过复杂的认证机制。他们仅仅是诱导用户在不知情的情况下，向其已登录的合法网站发送一个恶意的请求。这个请求在合法网站看来，是用户主动发起的，因此会被正常处理，从而导致用户在毫不知情的情况下执行了非预期的操作。想象一下，你正在浏览一个看似无害的网页，而你的银行账户却在后台悄然完成了一笔转账，这便是CSRF的可怕之处。

剖析CSRF的核心机制：信任的劫持

要有效地防御CSRF，我们首先必须透彻理解它的攻击原理。CSRF攻击本质上是一种“会话劫持”的变种，但它并非劫持会话本身，而是劫持了用户“以该会话身份”进行操作的“意图”。

1. CSRF攻击的工作流程

我们可以通过一个典型的场景来演示CSRF攻击是如何发生的：

  1. 用户登录合法网站： 假设用户A访问了一个银行网站（bank.com），并成功登录。银行网站服务器返回一个包含会话ID的Cookie（例如sessionid=XYZ），浏览器将其存储并与bank.com域关联。此时，用户A在bank.com的会话处于活跃状态。

    // 用户登录请求
POST /login HTTP/1.1
Host: bank.com
Content-Type: application/x-www-form-urlencoded

username=userA&password=secret

// 服务器响应
HTTP/1.1 200 OK
Set-Cookie: sessionid=XYZ; Path=/; HttpOnly; Secure

  2. 攻击者构造恶意页面： 攻击者B创建了一个恶意网站（attacker.com），并在其中嵌入了一个恶意请求。这个请求的目标是bank.com，意图执行一个敏感操作，例如转账。

    示例1：使用<img>标签发起GET请求
    如果bank.com有一个转账接口是GET请求（这是严重的设计缺陷，GET请求不应改变状态！），例如GET /transfer?toAccount=B&amount=1000，攻击者可以这样构造：

    <!-- attacker.com/malicious.html -->
<html>
<body>
    <h1>恭喜您中奖了！</h1>
    <img src="https://bank.com/transfer?toAccount=attackerAccount&amount=1000" style="display:none;" />
    <p>点击这里领取奖品！</p>
</body>
</html>

    示例2：使用<form>表单发起POST请求
    如果bank.com的转账接口是POST请求（更常见），攻击者可以构造一个自动提交的表单：

    <!-- attacker.com/malicious.html -->
<html>
<body>
    <h1>免费下载最新电影！</h1>
    <form id="csrfForm" action="https://bank.com/transfer" method="POST">
        <input type="hidden" name="toAccount" value="attackerAccount" />
        <input type="hidden" name="amount" value="1000" />
        <!-- 假设还有其他隐藏字段，如货币类型等 -->
    </form>
    <script>
        document.getElementById('csrfForm').submit(); // 页面加载后自动提交
    </script>
</body>
</html>

  3. 用户访问恶意页面： 攻击者通过钓鱼邮件、社交媒体或其他方式诱导用户A访问attacker.com/malicious.html。

  4. 浏览器自动发送请求（包含Cookie）： 当用户A的浏览器加载attacker.com/malicious.html时，它会尝试加载<img>标签或自动提交<form>表单。由于这个请求的目标是bank.com，并且用户A的浏览器中存储着bank.com的有效会话Cookie (sessionid=XYZ)，浏览器会自动将这个Cookie附加到请求中并发送给bank.com。

    // 浏览器发送的伪造请求
POST /transfer HTTP/1.1
Host: bank.com
Cookie: sessionid=XYZ // 关键点：浏览器自动带上了合法Cookie
Content-Type: application/x-www-form-urlencoded

toAccount=attackerAccount&amount=1000

  5. 合法网站处理请求： bank.com服务器收到请求后，会验证sessionid=XYZ，发现它是有效的。由于这个请求看起来就像是用户A自己发起的，服务器会执行转账操作，将1000元转到攻击者的账户。用户A对此毫不知情。

2. CSRF攻击的常见载体（Attack Vectors）

CSRF攻击可以利用多种HTML元素和浏览器行为：

  • <img> 标签： 最简单的载体，用于发起GET请求。浏览器加载图片时会发送请求。
  • <script> 标签： 同样可用于发起GET请求，加载JavaScript文件。
  • <link> 标签： 加载CSS文件等，也可用于GET请求。
  • <iframe> 标签： 可以加载整个页面，如果目标页面有自动提交的表单，同样可以触发CSRF。
  • <form> 表单提交： 这是最常见的载体，可发起GET或POST请求。通过JavaScript自动提交或诱导用户点击提交按钮。
  • AJAX 请求（较少用于传统CSRF）： 严格来说，由于同源策略（Same-Origin Policy，SOP）的限制，攻击者无法通过JavaScript直接跨域发起带有受限HTTP头的AJAX请求，也无法读取响应。然而，对于“简单请求”（Simple Requests，如GET、POST、HEAD且不包含自定义Header），浏览器不会进行预检（preflight），请求仍然会被发送，只是攻击者无法获取响应。

3. 关键的同源策略（SOP）与CSRF

这里需要强调SOP的作用。SOP规定，一个网页的脚本只能访问同源的资源。这意味着：

  • 攻击者在attacker.com上运行的JavaScript，无法直接读取bank.com的响应内容。
  • 攻击者无法通过JavaScript在跨域请求中添加任意的HTTP Header（例如，一个自定义的CSRF Token Header），除非服务器通过CORS预检明确允许。

CSRF攻击正是巧妙地避开了SOP的限制：它不要求攻击者读取响应，只需要攻击者能够发起请求，并且这个请求能够被目标网站“信任”即可。浏览器自动携带Cookie的机制，恰好为这种信任提供了“通行证”。

成功CSRF攻击的深远影响

CSRF攻击一旦成功，其后果可能非常严重，涵盖了数据、财务和声誉的多个层面：

  • 财务损失： 银行转账、在线购物、加密货币交易等，直接导致用户的资金流失。
  • 账户控制： 修改用户密码、邮箱、手机号，甚至绑定新的支付方式，从而完全劫持账户。
  • 数据篡改与删除： 在社交媒体上发布恶意内容、删除重要文档、修改个人资料等。
  • 权限升级： 如果受害者是管理员，攻击者可能利用其权限进行系统配置更改、用户管理等高危操作。
  • 会话终止： 强制用户退出登录，造成不便。

因此，对CSRF的防御绝非小事，而是Web应用安全的基石之一。

传统CSRF防御及其局限性

在SameSite Cookie属性出现之前，Web开发社区已经探索出一些防御CSRF的方法。这些方法在一定程度上有效，但也存在各自的局限性。

1. 区分GET和POST请求

这是一种基本但绝非万全的策略。永远不要让GET请求改变应用状态。 GET请求应该只用于查询数据，POST、PUT、DELETE等请求才用于数据修改。

  • 优点： 符合HTTP方法语义，避免了最简单的<img>标签CSRF攻击。
  • 局限性： 攻击者仍然可以通过<form method="POST">来伪造POST请求。所以，这仅仅是一个好的实践，而非CSRF防御机制。

2. Referer Header检查

Referer（注意，HTTP标准中是单r）Header指示了请求的来源页面。服务器可以检查这个Header，确保请求是来自自己的域名，而不是其他恶意网站。

  • 工作原理： 服务器在处理敏感请求时，检查HTTP请求头中的Referer字段。如果Referer指向的不是自己的域名，或者根本没有Referer字段，则拒绝该请求。

    // 假设在Node.js Express框架中
app.post('/transfer', (req, res) => {
    const referer = req.get('Referer');
    if (!referer || !referer.startsWith('https://bank.com')) {
        return res.status(403).send('CSRF: Invalid Referer');
    }
    // ... 处理转账逻辑
});

  • 局限性：

    • 用户隐私设置： 一些浏览器或用户隐私插件可能会阻止发送Referer Header，导致合法请求被拒绝。
    • 代理与防火墙： 中间代理或防火墙可能会清除或修改Referer Header。
    • SSL到HTTP跳转： 从HTTPS页面跳转到HTTP页面时，Referer Header可能被浏览器移除。
    • 绕过： 尽管困难，但在某些特定情况下（如Flash或一些浏览器插件漏洞），攻击者可能伪造Referer。此外，如果攻击通过某个开放重定向（open redirect）漏洞跳转到目标网站，Referer可能看起来是合法的。
    • 部分请求无Referer： 直接输入URL、从书签访问等，可能不带Referer。

3. Double-Submit Cookie

这种方法不需要服务器存储CSRF令牌，而是利用Cookie的特性。

  • 工作原理：

    1. 用户访问页面时，服务器生成一个随机的CSRF令牌，并将其设置在一个Cookie中（例如csrf_token_cookie），同时也在页面中的一个隐藏表单字段（例如csrf_token_field）中包含这个令牌。
    2. 当用户提交表单时，浏览器会自动发送csrf_token_cookie。
    3. 服务器接收到请求后，比较csrf_token_cookie的值和csrf_token_field的值。如果两者匹配，则认为是合法请求。

    后端（设置Cookie和页面令牌）

    # Flask 示例
from flask import Flask, request, make_response, session
import os

app = Flask(__name__)
app.secret_key = os.urandom(24) # 用于会话签名

@app.route('/login', methods=['GET', 'POST'])
def login():
    if request.method == 'POST':
        # ... 认证用户
        response = make_response("Logged in!")
        csrf_token = os.urandom(16).hex()
        response.set_cookie('csrf_token', csrf_token, httponly=False, samesite='Lax', secure=True)
        session['csrf_token'] = csrf_token # 也可以存储在服务器会话中
        return response
    return '''
        <form method="post">
            <input type="text" name="username" placeholder="Username">
            <input type="password" name="password" placeholder="Password">
            <button type="submit">Login</button>
        </form>
    '''

@app.route('/transfer', methods=['GET']) # GET来获取页面，POST来提交
def show_transfer_form():
    csrf_token = request.cookies.get('csrf_token')
    if not csrf_token:
        # 如果没有csrf_token cookie，生成一个新的并设置
        csrf_token = os.urandom(16).hex()
        response = make_response(f'''
            <form action="/transfer" method="post">
                <input type="text" name="toAccount" placeholder="To Account">
                <input type="number" name="amount" placeholder="Amount">
                <input type="hidden" name="csrf_token_field" value="{csrf_token}">
                <button type="submit">Transfer</button>
            </form>
        ''')
        response.set_cookie('csrf_token', csrf_token, httponly=False, samesite='Lax', secure=True)
        return response
    return f'''
        <form action="/transfer" method="post">
            <input type="text" name="toAccount" placeholder="To Account">
            <input type="number" name="amount" placeholder="Amount">
            <input type="hidden" name="csrf_token_field" value="{csrf_token}">
            <button type="submit">Transfer</button>
        </form>
    '''

@app.route('/transfer', methods=['POST'])
def transfer_money():
    cookie_token = request.cookies.get('csrf_token')
    form_token = request.form.get('csrf_token_field')

    if not cookie_token or not form_token or cookie_token != form_token:
        return "CSRF attack detected or invalid token!", 403

    # ... 执行转账逻辑
    return f"Transferred {request.form['amount']} to {request.form['toAccount']}"

  • 局限性：

    • XSS漏洞： 如果网站存在XSS漏洞，攻击者可以利用JavaScript读取或设置csrf_token Cookie，从而绕过此防御。
    • 子域攻击： 如果攻击者能够控制目标网站的某个子域，并且该子域可以设置父域的Cookie（例如，*.example.com的Cookie），则攻击者可以伪造csrf_token Cookie。
    • Requires JavaScript： 对于AJAX请求，前端需要JS来读取Cookie并将令牌加入请求。
    • HttpOnly Cookie： 为了防止XSS读取，Session Cookie通常设置为HttpOnly，但csrf_token_cookie必须不能是HttpOnly，以便前端JavaScript可以读取它并将其嵌入到表单或请求头中。这增加了XSS的风险。

CSRF Tokens：传统的行业标准

在SameSite Cookie属性广泛支持之前，CSRF Token（也称为Synchronizer Token Pattern）是业界公认且广泛采用的CSRF防御策略。其核心思想是为每个用户会话生成一个独特的、不可预测的、秘密的令牌，并确保所有改变状态的请求都包含这个令牌。

1. CSRF Token 的基本原理

  1. 生成令牌： 服务器在用户登录后，为该会话生成一个唯一的CSRF令牌。这个令牌通常是一个加密安全的随机字符串。
  2. 存储令牌： 服务器将这个令牌存储在用户会话中（例如，服务器端内存、数据库、或带签名的Cookie）。
  3. 嵌入令牌： 当服务器渲染包含表单或需要进行AJAX操作的页面时，会将这个令牌嵌入到页面中。
    • 对于HTML表单，令牌通常放在一个隐藏的<input>字段中。
    • 对于AJAX请求，令牌通常放在一个自定义的HTTP请求头中，或者作为请求体的一部分。
  4. 提交验证： 当用户提交表单或发起AJAX请求时，浏览器会将令牌随请求一起发送到服务器。
  5. 服务器验证： 服务器收到请求后，会从请求中提取令牌，并将其与存储在会话中的令牌进行比较。
    • 如果令牌匹配，请求被认为是合法的，并继续处理。
    • 如果令牌不匹配或缺失，请求被认为是伪造的，服务器会拒绝该请求并返回错误（例如403 Forbidden）。

2. CSRF Token 的实现示例（Python Flask）

后端实现：

# app.py (Flask 示例)
from flask import Flask, request, session, redirect, url_for, render_template_string, flash
import os
import secrets # Python 3.6+ for cryptographically strong random numbers

app = Flask(__name__)
app.secret_key = os.urandom(24) # 用于签名会话Cookie

# 简单的用户模拟
USERS = {'admin': 'password123'}

def generate_csrf_token():
    if 'csrf_token' not in session:
        session['csrf_token'] = secrets.token_urlsafe(16) # 生成一个URL安全的随机字符串
    return session['csrf_token']

@app.before_request
def csrf_protect():
    if request.method == "POST":
        # 对于所有POST请求，除非是登录请求，否则都验证CSRF token
        if request.endpoint == 'login' or request.endpoint == 'static':
            return # 登录和静态文件不需要CSRF保护

        expected_token = session.get('csrf_token')
        received_token = request.form.get('csrf_token') or request.headers.get('X-CSRF-TOKEN')

        if not expected_token or not received_token or expected_token != received_token:
            flash("CSRF token missing or incorrect. Request blocked.")
            return redirect(url_for('dashboard')) # 或者返回403 Forbidden
    # 对于GET请求，确保生成CSRF token
    if 'csrf_token' not in session:
        session['csrf_token'] = secrets.token_urlsafe(16)

@app.route('/')
def index():
    if 'username' in session:
        return redirect(url_for('dashboard'))
    return redirect(url_for('login'))

@app.route('/login', methods=['GET', 'POST'])
def login():
    if request.method == 'POST':
        username = request.form['username']
        password = request.form['password']
        if username in USERS and USERS[username] == password:
            session['username'] = username
            # 登录成功后，立即生成并存储CSRF Token
            session['csrf_token'] = secrets.token_urlsafe(16)
            flash('Logged in successfully!')
            return redirect(url_for('dashboard'))
        flash('Invalid credentials.')
        return render_template_string('''
            <h2>Login</h2>
            {% with messages = get_flashed_messages() %}
                {% if messages %}
                    <ul class=flashes>
                        {% for message in messages %}
                            <li>{{ message }}</li>
                        {% endfor %}
                    </ul>
                {% endif %}
            {% endwith %}
            <form action="/login" method="post">
                <input type="text" name="username" placeholder="Username" required><br>
                <input type="password" name="password" placeholder="Password" required><br>
                <button type="submit">Login</button>
            </form>
        ''')
    return render_template_string('''
        <h2>Login</h2>
        {% with messages = get_flashed_messages() %}
            {% if messages %}
                <ul class=flashes>
                    {% for message in messages %}
                        <li>{{ message }}</li>
                    {% endfor %}
                </ul>
            {% endif %}
        {% endwith %}
        <form action="/login" method="post">
            <input type="text" name="username" placeholder="Username" required><br>
            <input type="password" name="password" placeholder="Password" required><br>
            <button type="submit">Login</button>
        </form>
    ''')

@app.route('/dashboard')
def dashboard():
    if 'username' not in session:
        return redirect(url_for('login'))

    # 每次渲染页面时，确保CSRF token已在session中
    csrf_token = generate_csrf_token()

    return render_template_string('''
        <h2>Welcome, {{ session['username'] }}!</h2>
        <p>Your CSRF Token: <code>{{ csrf_token }}</code> (For demonstration purposes, normally hidden)</p>

        <h3>Make a Transfer (Form Submission)</h3>
        {% with messages = get_flashed_messages() %}
            {% if messages %}
                <ul class=flashes>
                    {% for message in messages %}
                        <li>{{ message }}</li>
                    {% endfor %}
                </ul>
            {% endif %}
        {% endwith %}
        <form action="/transfer" method="post">
            <input type="text" name="toAccount" placeholder="To Account" required><br>
            <input type="number" name="amount" placeholder="Amount" required><br>
            <input type="hidden" name="csrf_token" value="{{ csrf_token }}">
            <button type="submit">Transfer (Form)</button>
        </form>

        <h3>Make a Transfer (AJAX Submission)</h3>
        <input type="text" id="ajaxToAccount" placeholder="To Account (AJAX)" required><br>
        <input type="number" id="ajaxAmount" placeholder="Amount (AJAX)" required><br>
        <button onclick="makeAjaxTransfer()">Transfer (AJAX)</button>

        <script>
            function makeAjaxTransfer() {
                const toAccount = document.getElementById('ajaxToAccount').value;
                const amount = document.getElementById('ajaxAmount').value;
                const token = "{{ csrf_token }}"; // 从模板中获取token

                fetch('/transfer', {
                    method: 'POST',
                    headers: {
                        'Content-Type': 'application/json',
                        'X-CSRF-TOKEN': token // 将CSRF token放在自定义HTTP头中
                    },
                    body: JSON.stringify({ toAccount: toAccount, amount: amount })
                })
                .then(response => response.text())
                .then(data => alert(data))
                .catch(error => console.error('Error:', error));
            }
        </script>

        <hr>
        <a href="/logout">Logout</a>
    ''', username=session['username'], csrf_token=csrf_token)

@app.route('/transfer', methods=['POST'])
def transfer_money():
    if 'username' not in session:
        return redirect(url_for('login'))

    # CSRF token验证已在before_request中处理

    # 模拟处理转账
    if request.is_json:
        data = request.json
        to_account = data.get('toAccount')
        amount = data.get('amount')
    else:
        to_account = request.form.get('toAccount')
        amount = request.form.get('amount')

    flash(f"Successfully transferred {amount} to {to_account}!")
    return "Transfer successful!"

@app.route('/logout')
def logout():
    session.pop('username', None)
    session.pop('csrf_token', None) # 清除CSRF token
    flash('You have been logged out.')
    return redirect(url_for('login'))

if __name__ == '__main__':
    app.run(debug=True, port=5000)

前端（HTML模板片段）：

<!-- 对于表单提交 -->
<form action="/transfer" method="post">
    <input type="text" name="toAccount" placeholder="To Account"><br>
    <input type="number" name="amount" placeholder="Amount"><br>
    <input type="hidden" name="csrf_token" value="{{ csrf_token }}"> <!-- 隐藏字段携带令牌 -->
    <button type="submit">Transfer</button>
</form>

<!-- 对于AJAX提交 (JavaScript) -->
<script>
    function makeAjaxTransfer() {
        const toAccount = document.getElementById('ajaxToAccount').value;
        const amount = document.getElementById('ajaxAmount').value;
        const token = "{{ csrf_token }}"; // 从模板中获取令牌

        fetch('/transfer', {
            method: 'POST',
            headers: {
                'Content-Type': 'application/json',
                'X-CSRF-TOKEN': token // 将令牌作为自定义HTTP头发送
            },
            body: JSON.stringify({ toAccount: toAccount, amount: amount })
        })
        .then(response => response.text())
        .then(data => alert(data))
        .catch(error => console.error('Error:', error));
    }
</script>

3. CSRF Token 的挑战与考量

CSRF Token机制虽然强大，但也存在一些挑战：

  • 实现复杂性： 需要确保所有改变状态的请求都包含并验证令牌。在大型应用中，这可能意味着大量的手动工作，容易遗漏。
  • 状态管理： 服务器需要为每个会话存储CSRF令牌，这增加了服务器的内存或数据库开销。
  • 令牌同步： 如果用户在多个标签页中操作，或者使用了浏览器的“后退”按钮，可能会导致令牌过期或不匹配，影响用户体验。
  • XSS漏洞： CSRF令牌本身无法防御XSS。如果网站存在XSS漏洞，攻击者可以轻易地读取页面中的隐藏令牌，甚至通过JavaScript发起带有令牌的请求，完全绕过CSRF防御。
  • 无状态API： 对于无状态的API设计，CSRF令牌的服务器端存储会引入额外的状态。

尽管有这些挑战，CSRF Token在很长一段时间内都是对抗CSRF攻击的黄金标准。然而，随着Web技术的发展，我们有了更优雅、更底层的防御机制。

SameSite Cookie 属性：CSRF防御的新范式

SameSite Cookie属性是近年来Web安全领域的一项重大进展，它从浏览器层面直接解决了大部分CSRF攻击的根本问题——浏览器自动发送跨站Cookie的行为。

1. SameSite 的核心思想

SameSite 属性指示浏览器，在何种情况下可以随着跨站请求发送Cookie。通过限制Cookie的发送范围，它能够有效地阻止攻击者利用用户已登录的会话发起伪造请求。

2. SameSite 的三种模式

SameSite 属性有三个可能的值：Strict、Lax 和 None。

SameSite 值 描述 保护级别 影响用户体验 适用场景
Strict 最严格。 浏览器在任何跨站请求中都不会发送Cookie。只有当请求来自与Cookie所关联的站点完全相同的站点时，才会发送Cookie。 最高 会影响用户体验。例如，从外部网站点击链接跳转到你的网站时，用户需要重新登录。 适用于对安全性要求极高的应用，且不涉及跨站跳转或第三方集成的场景。
Lax 折中方案。 浏览器在以下两种情况发送Cookie：1. 请求来自与Cookie关联的站点。2. 跨站的顶层导航（Top-level navigation）GET请求。 中高 较好地平衡了安全和用户体验。允许从外部链接（GET请求）跳转到你的网站并保持登录状态，但阻止POST等改变状态的跨站请求。 大多数Web应用的推荐默认值。既能有效防御CSRF，又能维持基本的跨站链接体验。
None 不限制。 浏览器在所有请求中都发送Cookie，包括跨站请求。必须与Secure属性一同使用（即只能在HTTPS连接下发送）。 无 不影响用户体验。允许所有跨站Cookie发送，适用于需要跨站共享Cookie的场景（如第三方嵌入、SSO）。 仅用于需要明确进行跨站Cookie共享的场景，且必须结合其他CSRF防御机制（如CSRF Token或自定义Header）。

3. SameSite 的浏览器默认行为演进（重要！）

  • 早期（2017-2019）： SameSite属性是可选的，如果未指定，默认行为与None类似（即所有请求都发送Cookie）。这使得许多旧应用容易受到CSRF攻击。
  • 现代（2020年起）： Chrome 80+、Firefox 79+ 等主流浏览器开始将SameSite的默认值从“无”改为Lax。这意味着，即使你的应用没有明确设置SameSite属性，其会话Cookie也会默认受到Lax模式的保护。这是一个里程碑式的安全改进。
  • 要求Secure： 如果你明确设置SameSite=None，则必须同时设置Secure属性，表示Cookie只能通过HTTPS连接发送。否则，浏览器会拒绝该Cookie。

4. SameSite 的实现示例

SameSite属性是在设置Cookie时，在HTTP响应头中添加的。

HTTP响应头示例：

Set-Cookie: sessionid=XYZ; Path=/; HttpOnly; Secure; SameSite=Lax
Set-Cookie: preferences=theme_dark; Path=/; Secure; SameSite=Strict
Set-Cookie: third_party_tracker=ABC; Path=/; Secure; SameSite=None

后端框架示例：

几乎所有现代Web框架都提供了设置SameSite属性的API。

Python Flask：

from flask import Flask, make_response, session, redirect, url_for, render_template_string
import os
import secrets

app = Flask(__name__)
app.secret_key = os.urandom(24) # 用于签名会话Cookie

@app.route('/login', methods=['POST'])
def login():
    # ... 验证用户
    if True: # 假设验证成功
        session['username'] = 'testuser'
        response = make_response("Logged in!")
        # Flask的session Cookie默认就是Secure和HttpOnly，并且通常会遵循Flask配置的SameSite设置。
        # 你可以通过app.config['SESSION_COOKIE_SAMESITE']='Lax' 来全局设置。
        # 对于非session的普通Cookie，可以手动设置：
        response.set_cookie('my_custom_cookie', 'some_value', httponly=True, secure=True, samesite='Lax')
        return response
    return "Login Failed"

@app.route('/transfer', methods=['POST'])
def transfer_money():
    if 'username' not in session:
        return redirect(url_for('login'))

    # 理论上，如果session Cookie是SameSite=Lax，
    # 并且这个POST请求是从第三方网站发起的，
    # 浏览器就不会发送session Cookie，从而阻止CSRF。

    # ... 处理转账逻辑
    return "Transfer successful!"

# 注意：Flask默认的session Cookie通常是Secure, HttpOnly，
# 且可以通过配置设置SameSite。
# 例如，在app.py中添加：
app.config['SESSION_COOKIE_SAMESITE'] = 'Lax'
app.config['SESSION_COOKIE_SECURE'] = True # 确保Cookie只通过HTTPS发送
app.config['SESSION_COOKIE_HTTPONLY'] = True # 防止客户端脚本访问Cookie

if __name__ == '__main__':
    app.run(debug=True, port=5000, ssl_context='adhoc') # 使用adhoc SSL上下文进行HTTPS测试

Node.js Express (使用cookie-parser和express-session)：

const express = require('express');
const session = require('express-session');
const cookieParser = require('cookie-parser');
const app = express();
const https = require('https');
const fs = require('fs');

// 对于HTTPS，你需要SSL证书。这里使用自签名证书作为示例。
const privateKey = fs.readFileSync('server.key', 'utf8');
const certificate = fs.readFileSync('server.crt', 'utf8');
const credentials = { key: privateKey, cert: certificate };

app.use(express.json());
app.use(express.urlencoded({ extended: true }));
app.use(cookieParser());

app.use(session({
    secret: 'mysecretkey', // 用于签名会话ID的密钥
    resave: false,
    saveUninitialized: false,
    cookie: {
        secure: true, // 仅在HTTPS下发送Cookie
        httpOnly: true, // 客户端JS无法访问
        sameSite: 'Lax', // 关键的SameSite属性
        maxAge: 1000 * 60 * 60 * 24 // 1天
    }
}));

// 简单的用户模拟
const USERS = { 'admin': 'password123' };

app.get('/', (req, res) => {
    if (req.session.user) {
        return res.send(`Hello, ${req.session.user}! <a href="/logout">Logout</a><br><a href="/dashboard">Dashboard</a>`);
    }
    res.send('<a href="/login">Login</a>');
});

app.get('/login', (req, res) => {
    res.send(`
        <h2>Login</h2>
        <form action="/login" method="post">
            <input type="text" name="username" placeholder="Username" required><br>
            <input type="password" name="password" placeholder="Password" required><br>
            <button type="submit">Login</button>
        </form>
    `);
});

app.post('/login', (req, res) => {
    const { username, password } = req.body;
    if (USERS[username] === password) {
        req.session.user = username;
        return res.redirect('/');
    }
    res.status(401).send('Invalid credentials');
});

app.get('/dashboard', (req, res) => {
    if (!req.session.user) {
        return res.redirect('/login');
    }
    res.send(`
        <h2>Dashboard for ${req.session.user}</h2>
        <p>This is a sensitive page.</p>
        <form action="/transfer" method="post">
            <input type="text" name="toAccount" placeholder="To Account" required><br>
            <input type="number" name="amount" placeholder="Amount" required><br>
            <button type="submit">Transfer (Form)</button>
        </form>
        <hr>
        <a href="/logout">Logout</a>
    `);
});

app.post('/transfer', (req, res) => {
    if (!req.session.user) {
        return res.status(403).send('Not authenticated');
    }
    const { toAccount, amount } = req.body;
    // 如果 SameSite=Lax 生效，并且请求是从第三方站点以POST方式发起的，
    // 那么 req.session.user 将不存在，因为 session Cookie 不会被发送。
    console.log(`Transferring ${amount} to ${toAccount} for user ${req.session.user}`);
    res.send(`Transfer of ${amount} to ${toAccount} successful!`);
});

app.get('/logout', (req, res) => {
    req.session.destroy(err => {
        if (err) return res.status(500).send('Could not log out');
        res.clearCookie('connect.sid', { secure: true, sameSite: 'Lax' }); // 清除会话Cookie
        res.redirect('/');
    });
});

const httpsServer = https.createServer(credentials, app);

httpsServer.listen(3000, () => {
    console.log('HTTPS Server running on port 3000');
});

注意： 为了运行上述Node.js示例，你需要生成自签名SSL证书。可以使用OpenSSL：
openssl req -x509 -newkey rsa:2048 -nodes -keyout server.key -out server.crt -days 365

5. SameSite 的局限性

尽管SameSite属性是强大的CSRF防御机制，但它并非完美无缺：

  • 不防范所有CSRF：
    • Lax模式不阻止顶层导航的GET请求。如果你的应用允许GET请求修改状态（这是一个严重的反模式！），那么SameSite=Lax无法防御这种CSRF。
    • SameSite=None模式不提供任何CSRF保护。如果你的应用需要跨站发送Cookie（例如，第三方组件、单点登录），并且设置了SameSite=None，那么就需要额外的CSRF保护。
  • 浏览器兼容性： 虽然主流浏览器已广泛支持并默认Lax，但仍有少量老旧浏览器可能不支持。
  • 不防范XSS： SameSite属性与CSRF Token一样，无法防御XSS攻击。XSS允许攻击者在受害者浏览器中执行任意JavaScript，从而绕过所有基于Cookie和请求头的CSRF防御。

自定义Header：另一层坚固的保障

在某些情况下，例如当我们需要SameSite=None来支持跨域功能时，或者作为一种深度防御策略，仅仅依靠SameSite是不够的。此时，引入自定义Header可以提供另一层强大的保障。

1. 自定义Header的防御原理

这种防御策略的核心思想是利用同源策略（SOP）和CORS（Cross-Origin Resource Sharing）预检机制对“非简单请求”的限制。

  • 简单请求（Simple Requests）： GET、HEAD、POST请求，且只使用少量标准HTTP头（Accept, Accept-Language, Content-Language, Content-Type且Content-Type的值只能是application/x-www-form-urlencoded, multipart/form-data, text/plain）。浏览器会直接发送这些请求，不进行预检。
  • 非简单请求（Non-Simple Requests）： 任何其他HTTP方法（PUT, DELETE等），或者使用了自定义HTTP头，或者使用了非标准Content-Type（如application/json）。浏览器在发送实际请求之前，会先发送一个OPTIONS预检请求（Preflight Request）到目标服务器，询问是否允许该跨域请求。

攻击者通过标准的HTML标签（如<img>, <form>) 无法添加自定义的HTTP头。他们需要使用JavaScript (XMLHttpRequest 或 Fetch API)。然而，如果他们试图通过JavaScript从attacker.com向bank.com发起带有自定义Header的请求，浏览器会：

  1. 首先发送一个OPTIONS预检请求。
  2. 如果服务器没有通过CORS响应头明确允许attacker.com源访问，并且没有允许该自定义Header，浏览器就会阻止实际请求的发送。

因此，通过要求在所有敏感的API请求中包含一个自定义的、非标准的HTTP头，我们可以有效地阻止CSRF攻击。

2. 实现示例：要求 X-Requested-With Header

许多Web框架和库（如jQuery）在发起AJAX请求时会自动添加X-Requested-With: XMLHttpRequest这样的自定义头。我们可以利用这一点进行防御。

后端实现（Node.js Express）：

// ... (前面Express的配置，包括session, cookie-parser等)

app.post('/transfer-ajax', (req, res) => {
    if (!req.session.user) {
        return res.status(403).send('Not authenticated');
    }

    // 关键防御：检查自定义Header
    const xRequestedWith = req.get('X-Requested-With');
    if (!xRequestedWith || xRequestedWith !== 'XMLHttpRequest') {
        // 如果没有X-Requested-With或者值不正确，视为CSRF攻击
        return res.status(403).send('CSRF: Custom header check failed.');
    }

    const { toAccount, amount } = req.body;
    console.log(`AJAX Transferring ${amount} to ${toAccount} for user ${req.session.user}`);
    res.json({ message: `AJAX Transfer of ${amount} to ${toAccount} successful!` });
});

// 为了让前端AJAX请求能成功，还需要配置CORS，但要非常谨慎！
// 生产环境中，Access-Control-Allow-Origin 应该指定为你的前端域名，而不是 '*'
app.use((req, res, next) => {
    res.header('Access-Control-Allow-Origin', 'https://your-frontend-domain.com'); // 明确指定允许的来源
    res.header('Access-Control-Allow-Methods', 'GET, POST, OPTIONS');
    res.header('Access-Control-Allow-Headers', 'Content-Type, X-Requested-With'); // 明确允许自定义Header
    res.header('Access-Control-Allow-Credentials', 'true'); // 允许发送Cookie
    if (req.method === 'OPTIONS') {
        return res.sendStatus(200);
    }
    next();
});

// ... (其他路由和服务器启动)

前端实现（JavaScript Fetch API）：

<!-- 在你的合法网站 (例如：https://your-frontend-domain.com) -->
<script>
    function makeAjaxTransferWithCustomHeader() {
        const toAccount = document.getElementById('ajaxToAccount').value;
        const amount = document.getElementById('ajaxAmount').value;

        fetch('https://your-backend-domain.com/transfer-ajax', {
            method: 'POST',
            credentials: 'include', // 确保发送Cookie
            headers: {
                'Content-Type': 'application/json',
                'X-Requested-With': 'XMLHttpRequest' // 关键：包含自定义Header
            },
            body: JSON.stringify({ toAccount: toAccount, amount: amount })
        })
        .then(response => response.json())
        .then(data => alert(data.message))
        .catch(error => console.error('Error:', error));
    }
</script>

3. 自定义Header的优点与局限性

优点：

  • 利用SOP和CORS预检： 这是其防御的基础，攻击者难以绕过。
  • 无状态： 服务器无需存储令牌，简化了状态管理。
  • 与SameSite互补： 即使SameSite=None或其他机制失效，自定义Header仍能提供保护。
  • 实现相对简单： 只需要前端添加Header，后端验证Header。

局限性：

  • 不防简单请求： 无法防御不带自定义Header的简单GET/POST请求。因此，所有改变状态的操作都应该使用非简单请求（例如，POST并要求自定义Header，或使用application/json）。
  • CORS配置复杂性： 错误的CORS配置（例如，Access-Control-Allow-Origin: * 且允许自定义Header）会彻底破坏这种防御。必须精确地指定允许的来源和Header。
  • XSS漏洞： XSS仍然可以绕过此防御，因为恶意脚本可以在同源上下文中执行，并合法地发起带有自定义Header的请求。

双重保障：SameSite Cookie属性与自定义Header的协同防御

现在我们来到今天讲座的核心：如何将SameSite Cookie属性和自定义Header结合起来，构建一个强大的双重保障，实现深度防御。

1. 协同防御的逻辑

这两种机制从不同层面提供了保护：

  • SameSite=Lax (或 Strict)：

    • 在浏览器层面阻止了大多数跨站请求自动携带敏感的会话Cookie。
    • 主要防御通过<form>提交、<img>加载等传统方式发起的CSRF攻击。
    • 缺点是Lax模式仍然允许顶层导航的GET请求携带Cookie，且None模式完全不提供保护。

  • 自定义Header：

    • 在应用层面利用SOP和CORS预检机制，确保只有经过授权（通过CORS预检）且包含特定Header的“非简单请求”才能成功。
    • 主要防御通过JavaScript发起的跨站AJAX请求。
    • 即使SameSite设置为None（例如，为了支持第三方集成），自定义Header仍然能够提供保护，因为它依赖于服务器端对请求头的验证和浏览器对CORS预检的强制执行。

当两者结合时，我们构建了一个多层次的防御体系：

  1. 浏览器默认行为 (SameSite=Lax/Strict)： 绝大多数情况下，敏感Cookie根本不会随着跨站请求发送，从而在源头阻止了CSRF。
  2. 自定义Header (针对AJAX等)： 对于那些需要跨域通信的场景（可能SameSite=None），或者作为对SameSite=Lax的补充，自定义Header会确保只有合法的、由前端JS主动添加的请求才能通过。

2. 双重保障的实施策略

为了实现这种双重保障，我们需要在后端和前端采取以下措施：

后端策略：

  1. 所有会话Cookie和认证Cookie： 务必设置Secure、HttpOnly，并优先使用SameSite=Lax。如果某些Cookie确实需要在跨站请求中发送（如OAuth、第三方SSO），则将其设置为SameSite=None，但必须同时设置Secure。 
    Set-Cookie: sessionid=XYZ; Path=/; HttpOnly; Secure; SameSite=Lax
Set-Cookie: sso_token=ABC; Path=/; HttpOnly; Secure; SameSite=None // 如果是跨站SSO需要

  2. 所有改变状态的API端点：

    • 检查HTTP方法： 确保GET请求不改变状态。
    • 要求自定义Header： 对于所有POST、PUT、DELETE请求，或者任何处理敏感操作的AJAX请求，要求客户端必须包含一个特定的自定义Header。例如，X-Requested-With: XMLHttpRequest 或一个更具业务含义的 X-App-CSRF-Protection: true。
    • 严格的CORS配置： 这是自定义Header防御的关键。
      • Access-Control-Allow-Origin：绝不设置为*（除非是公共API且不涉及认证信息），应明确列出你的前端应用域名。
      • Access-Control-Allow-Methods：明确允许所需的HTTP方法。
      • Access-Control-Allow-Headers：明确允许Content-Type和你自定义的Header。
      • Access-Control-Allow-Credentials：如果请求需要携带Cookie，必须设置为true。
    // Node.js Express 示例 (简化版)
app.post('/api/sensitive-action', (req, res) => {
    // 1. 检查SameSite (由浏览器自动处理，如果SameSite=Lax，跨站POST不会带Cookie)
    if (!req.session.user) { // 如果session Cookie没过来，说明是跨站请求，或者未登录
        return res.status(403).send('Not authenticated or CSRF detected (SameSite protection)');
    }

    // 2. 检查自定义Header (第二层保障)
    const customHeader = req.get('X-App-CSRF-Protection');
    if (!customHeader || customHeader !== 'true') {
        return res.status(403).send('CSRF detected (Custom Header protection)');
    }

    // ... 处理敏感操作
    res.status(200).send('Action successful!');
});

// CORS配置 (关键！)
app.use((req, res, next) => {
    const allowedOrigins = ['https://your-frontend-domain.com'];
    const origin = req.headers.origin;
    if (allowedOrigins.includes(origin)) {
        res.header('Access-Control-Allow-Origin', origin);
    }
    res.header('Access-Control-Allow-Methods', 'POST, GET, OPTIONS, PUT, DELETE');
    res.header('Access-Control-Allow-Headers', 'Content-Type, X-App-CSRF-Protection'); // 允许自定义Header
    res.header('Access-Control-Allow-Credentials', 'true'); // 允许发送Cookie
    if (req.method === 'OPTIONS') {
        return res.sendStatus(200); // 处理CORS预检请求
    }
    next();
});

前端策略 (JavaScript)：

  1. 所有AJAX请求： 在发送敏感的AJAX请求时，确保包含后端要求的自定义Header。同时，设置credentials: 'include'以确保浏览器发送Cookie。 
    // 在 your-frontend-domain.com
fetch('https://your-backend-domain.com/api/sensitive-action', {
    method: 'POST',
    credentials: 'include', // 确保浏览器发送session Cookie
    headers: {
        'Content-Type': 'application/json',
        'X-App-CSRF-Protection': 'true' // 包含自定义Header
    },
    body: JSON.stringify({ data: 'some sensitive data' })
})
.then(response => response.text())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

3. 为什么是双重保障？

  • 互补性： SameSite=Lax主要防御了传统表单提交方式的CSRF，而自定义Header主要防御了JavaScript发起的跨站非简单请求。两者结合，覆盖了更广的攻击面。
  • 深度防御： 即使攻击者找到了绕过SameSite=Lax的边缘情况（例如，利用某些浏览器怪癖），自定义Header的检查仍然会阻止请求。反之亦然。
  • 适应性： 对于必须使用SameSite=None的场景，自定义Header或CSRF Token就成了不可或缺的防御。这种双重保障策略允许我们在特定场景下灵活调整Cookie的SameSite属性，同时不牺牲CSRF防护。

核心防御之外：最佳实践与高级考量

除了SameSite Cookie和自定义Header的双重保障，还有一些通用的Web安全最佳实践，对于构建一个健壮的系统至关重要。

  • 幂等性： 再次强调，GET请求绝不能改变服务器状态。它们应该只用于检索信息。所有改变状态的操作（如创建、更新、删除）都应该通过POST、PUT、DELETE等HTTP方法进行。这是最基本的安全设计原则。
  • 严格的认证和授权： 对于所有敏感操作，不仅要验证用户身份，还要确认用户是否具备执行该操作的权限。对于特别敏感的操作（如修改密码、提现），可以要求用户重新认证。
  • Referer Header作为辅助检查： 尽管Referer Header有局限性，但在作为辅助检查时仍有价值。例如，可以结合SameSite和自定义Header，如果Referer也匹配，则增加信心；如果不匹配但其他检查通过，可以记录日志以供分析。
  • 强大的会话管理：
    • 会话ID应足够随机且长度足够。
    • 会话Cookie应始终设置HttpOnly和Secure属性。
    • 会话应有合理的过期时间，并且在用户登出、修改密码等操作后立即失效。
  • XSS防护： CSRF的防御机制无法防御XSS。 XSS攻击允许攻击者在用户的浏览器中执行任意JavaScript代码，从而能够完全模拟用户行为，包括读取CSRF Token、发送带有自定义Header的请求、甚至绕过SameSite限制。因此，对所有用户输入进行严格的输出编码（HTML编码、URL编码、JavaScript编码等）以防止XSS是Web安全的首要任务。
  • Content Security Policy (CSP)： CSP是一种HTTP响应头，允许网站管理员限制浏览器可以加载哪些资源（脚本、样式、图片、字体等）的来源。它可以有效地阻止XSS攻击，并通过限制表单提交的目标来间接增强CSRF防御，但主要不是为CSRF设计的。
  • 定期安全审计和渗透测试： 没有任何防御是百分之百完美的。定期对应用程序进行安全审计和渗透测试，可以发现潜在的漏洞和配置错误。
  • 用户教育： 提高用户对网络钓鱼和社会工程学攻击的警惕性，让他们警惕点击不明链接或下载不明文件。

构筑多层安全防线

综上所述，CSRF攻击是一个复杂而隐蔽的威胁，但通过结合现代浏览器特性和应用层面的防御策略，我们可以构建一个强大的防御体系。SameSite Cookie属性为我们提供了浏览器层面的第一道防线，它以一种优雅且不侵入应用逻辑的方式，解决了大部分传统CSRF问题。而自定义Header则作为第二道防线，尤其适用于AJAX请求和需要跨域共享Cookie的场景，利用了浏览器同源策略的天然屏障。

在实际开发中，我们应该始终秉持“深度防御”的理念，不依赖单一的安全措施。将SameSite=Lax（或Strict）设置为默认，并辅以自定义Header进行关键操作的验证，同时不忘CSRF Token作为备用或特定场景的补充，以及严格的XSS防护和良好的安全实践，才能真正为我们的Web应用提供坚实可靠的保护。安全是一场永无止境的博弈，持续学习、持续改进，是每一位编程专家肩负的责任。

感谢大家！

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注