《白帽子讲 Web 安全》之跨站请求伪造

引言

在数字化时代，网络已深度融入人们生活的方方面面，Web 应用如雨后春笋般蓬勃发展，为人们提供着便捷高效的服务。然而，繁荣的背后却潜藏着诸多安全隐患，**跨站请求伪造（CSRF）**便是其中极为隐蔽且危险的一种。它如同隐匿在暗处的黑客，趁用户在 Web 世界中畅游时，悄然发动攻击，严重威胁着用户的账户安全以及 Web 应用的稳定与信誉。吴翰清在《白帽子讲 Web 安全》中对其进行了深入剖析，接下来，让我们一同揭开 CSRF 的神秘面纱，深入剖析其原理、攻击手段与防御策略。

一、CSRF 简介

定义

CSRF，即Cross Site Request Forgery 的缩写，是一种常见且隐蔽的 Web 攻击 手段。攻击者精心设计诱导策略，使已登录目标网站的用户访问恶意网站，进而利用用户在目标网站的身份权限，在用户毫不知情的情况下，在目标网站执行非用户本意的操作。这一过程中，攻击者无需获取用户的登录凭证，仅借助浏览器的特性就可达成攻击目的。

示例

以社交网站为例，假设该网站的 "添加关注" 功能通过向http://example.com/follow?id=USERID发送 GET 请求来实现。当用户已登录example.com，此时若访问了恶意网站，而恶意网站中嵌入了<img src="http://example.com/follow?id=1234"/>。由于浏览器会自动加载图片，便会向该链接发送 GET 请求。又因为用户已登录example.com，浏览器会自动携带该网站的 Cookie，目标网站基于 Cookie 验证用户身份，将此请求视为用户的正常操作，最终导致用户在不知情的状况下关注了 UID 为 1234 的用户。

二、CSRF 详解

1.本质

CSRF 攻击成功的关键在于巧妙利用浏览器自动携带用户已登录网站 Cookie 的特性 。当用户访问恶意网站时，恶意网站精心构造的请求会借助浏览器的自动行为，以用户身份被发送到目标网站。目标网站仅依据请求中携带的Cookie 来验证用户身份，却无法判断该请求究竟是用户的真实意愿，还是攻击者伪造的。这种机制使得攻击者能够在用户不知情的情况下，在目标网站执行各种操作，如转账、修改用户信息等，给用户带来极大的损失。

2.GET 和 POST 请求

GET 请求

攻击者通常通过构造包含恶意操作的URL 发起 GET 请求攻击。在恶意网站中设置一个图片链接，其src属性为目标网站的操作 URL，是常见的攻击手段。当用户访问恶意网站时，浏览器自动向该 URL 发送 GET 请求，恶意操作得以执行。

假设目标网站有一个删除用户评论的操作，对应的 URL 为http://example.com/delete_comment?id=COMMENTID。攻击者在恶意网站嵌入<img src="http://example.com/delete_comment?id=5678"/>，若用户已登录example.com且该评论属于此用户，那么用户在访问恶意网站时，浏览器会自动发送请求，导致用户的评论被删除。

POST 请求

对于POST 请求 ，攻击者常采用自动提交表单的方式。在恶意网站中隐藏一个自动提交的表单，表单的action属性为目标网站的操作 URL。当用户访问恶意网站时，该表单会自动提交，以用户身份执行 POST 请求。

比如，目标网站有一个修改用户密码的功能，通过 POST 请求将新密码发送到http://example.com/change_password。攻击者在恶意网站创建如下表单：

<form action="http://example.com/change_password" method="post" style="display:none;">

<input type="hidden" name="new_password" value="attacker_password">

</form>

<script>

document.forms[0].submit();

</script>

当用户登录example.com后访问该恶意网站，表单会自动提交，用户的密码就被修改为攻击者设置的密码。

3.CSRF 蠕虫

CSRF 蠕虫 是一种极其危险的 CSRF 攻击形式，其危害性远超普通的 CSRF 攻击。攻击者利用网站的 CSRF 漏洞，结合XSS 攻击手段（例如通过 XSS 获取用户的好友列表），实现恶意操作的自动传播。举例来说，攻击者在用户页面自动发布包含恶意链接的内容，当其他用户访问该页面时，就会触发 CSRF 攻击。

假设某社交平台存在 CSRF 漏洞，攻击者利用 XSS 在用户 A 的页面发布一条动态，内容为<img src="http://example.com/send_spam?message=恶意广告内容&to=USERID"/>，其中USERID通过 XSS 获取的用户 A 的好友列表动态生成。当用户 A 的好友浏览其页面时，浏览器会自动向目标网站发送请求，以该好友的身份向其他用户发送恶意广告，如此循环，攻击范围像滚雪球一样迅速扩大，对整个社交平台的用户体验和安全造成严重影响。

三、防御 CSRF 攻击

1.验证码

在用户进行关键操作时，要求输入验证码是一种有效的防御 CSRF 攻击的手段。由于验证码只有用户可见，攻击者无法获取并伪造，这就确保了请求是用户的真实操作。

例如，在进行转账操作时，银行网站要求用户输入图形验证码或短信验证码。用户需要在页面上查看并输入验证码，只有输入正确才能完成转账。然而，频繁要求用户输入验证码会极大地影响用户体验，导致用户在使用过程中感到繁琐和不便，所以在实际应用中，需要在安全性和用户体验之间找到平衡，不能过度依赖验证码。

2.Referer 校验

通过检查 HTTP 请求中的 Referer 字段 ，Web 应用可以判断请求的来源是否合法。正常情况下，用户在目标网站内部进行操作时，请求的 Referer 应该是目标网站的内部页面。若 Referer 字段显示请求来自恶意网站 ，那么服务器 可以拒绝该请求。

例如，用户在example.com进行修改个人信息的操作，该操作的请求 Referer 应该是example.com的相关页面，如个人设置页面。如果服务器接收到的请求 Referer 为MALICIOUS.COM，则很可能是 CSRF 攻击，服务器可直接拒绝。但需要注意的是，Referer 字段并非完全可靠。一方面，攻击者可以通过技术手段伪造 Referer 字段，使其看起来像是来自合法的来源；另一方面，在某些特殊情况下，如从 HTTPS 页面跳转到 HTTP 页面时，由于安全策略等原因，Referer 字段可能为空。因此，仅依靠 Referer 校验并不能完全确保应用免受 CSRF 攻击，它只能作为一种辅助的防御手段。

3.Anti - CSRF Token

原理

Anti - CSRF Token 是目前防御 CSRF 攻击最为常用且有效的方法之一。在用户登录或页面加载时，服务器会生成一个随机的 Token ，并将其存储在用户的 Session 中。同时，服务器通过隐藏表单字段或 HTTP 头的方式将 Token 发送给客户端。当客户端发起请求时，会将 Token 包含在请求中。服务器在接收到请求后，会验证 Token 的有效性和一致性，即检查请求中的 Token 与存储在 Session 中的 Token 是否匹配。若两者不匹配 ，服务器将拒绝请求，从而有效阻止 CSRF 攻击。

使用原则

为了确保 Anti - CSRF Token 的有效性，需要遵循一些重要原则。首先，Token 要足够随机且难以预测，避免使用固定值或可猜测的值。

例如，使用高强度的加密算法生成 Token，保证其具有足够的长度和复杂度。其次，在不同页面或操作中，Token 应保持唯一性 ，防止攻击者通过复用 Token 来绕过防御机制。最后，服务器端要正确验证 Token ，防止重放攻击等。例如，在验证 Token 后，及时将其从 Session 中移除或标记为已使用，确保同一个 Token 不会被多次使用。

示例

在 HTML 表单中添加一个隐藏的input字段来存储 Token 是常见的做法。例如：

<form action="http://example.com/do_something" method="post">

<input type="hidden" name="csrf_token" value="随机生成的Token值"/>

<!-- 其他表单字段 -->

<input type="submit" value="提交">

</form>

服务器端在处理请求时，会获取该 Token，并与存储在 Session 中的 Token 进行比对。以 Python 的 Flask 框架为例，代码如下：

from flask import Flask, request, session

app = Flask(__name__)

app.secret_key = 'your_secret_key'

@app.route('/generate_token')

def generate_token():

    import secrets

    token = secrets.token_hex(16)

    session['csrf_token'] = token
    
    return token

@app.route('/do_something', methods=['POST'])

def do_something():

    if 'csrf_token' not in session or 'csrf_token' not in request.form:

        return 'CSRF验证失败', 403

    if session['csrf_token'] != request.form['csrf_token']:
    
        return 'CSRF验证失败', 403

# 处理正常业务逻辑

    return '操作成功'

在上述代码中，/generate_token路由用于生成 Token 并存储在 Session 中，/do_something路由在处理 POST 请求时，会验证请求中的 Token 与 Session 中的 Token 是否一致，若一致则处理正常业务逻辑，否则返回 CSRF 验证失败的提示。

四、相关要点

1.与 XSS 的关联

CSRF 和 XSS 作为 Web 安全中的两大重要问题，它们之间存在着紧密的关联。XSS 攻击可用于获取用户的Cookie 等敏感信息，而这些信息正是 CSRF 攻击所依赖的。攻击者通过XSS 将恶意脚本注入到用户浏览的页面中，当用户访问该页面时，恶意脚本会获取用户的 Cookie ，并将其发送给攻击者。攻击者利用获取到的 Cookie，结合 CSRF 攻击 手段，就可以以用户的身份在目标网站执行各种操作。另一方面，CSRF 攻击也可能结合 XSS 来扩大攻击范围和影响。例如，通过 CSRF 攻击在用户页面植入 XSS 代码，当其他用户访问该页面时，就会触发 XSS 攻击，进一步传播恶意代码，造成更大的危害。

2.常见应用场景

许多 Web 应用都存在 CSRF 风险，尤其是涉及用户资金交易、个人信息修改、关注点赞等操作的功能。在金融类应用中，若存在 CSRF 漏洞，攻击者可能诱导用户在已登录状态下执行转账操作，导致用户资金损失。在社交平台上，攻击者可能利用 CSRF 漏洞，以用户的名义发布不良信息、修改用户个人资料或关注恶意账号等。因此，开发者在开发 Web 应用时，应高度重视这些关键功能的安全性，采取有效的防御措施，防止 CSRF 攻击的发生。

3.不同框架的应对

不同的 Web 开发框架，如 Flask、Django、Spring 等，通常都提供了相应的 CSRF 防护机制或扩展。以 Flask 框架为例，可通过Flask - WTF扩展来实现 CSRF 防护。使用时，只需在应用中初始化扩展，并在表单中添加 CSRF 保护字段即可。例如：

from flask import Flask

from flask_wtf.csrf import CSRFProtect

app = Flask(__name__)

app.secret_key = 'your_secret_key'

csrf = CSRFProtect(app)

# 其他路由和视图函数

在 HTML 表单中，使用Flask - WTF生成 CSRF 保护字段：

{{ form.csrf_token }}

通过这种方式，开发者可以利用框架提供的工具轻松增强应用的安全性。但需要注意的是，在使用这些工具时，要正确配置和使用，仔细阅读框架文档，避免因配置不当而出现漏洞，确保应用能够有效抵御 CSRF 攻击。

总结

跨站请求伪造（CSRF）是一个复杂且不断演变的 Web 安全问题。无论是开发者、安全研究人员还是普通用户，都需要持续关注其发展动态。开发者要将安全意识贯穿于整个开发周期，不仅要熟练运用现有的防御技术，还要积极探索新的安全防护手段；安全研究人员需深入研究攻击者的新手法，为安全防护提供理论支持；而普通用户则要提高自身的安全意识，谨慎点击不明链接，避免访问可疑网站。只有各方共同努力，才能在这场与 CSRF 攻击的较量中取得胜利，保障 Web 应用的安全和用户的权益。

喜欢就点点赞和评论关注一起进步呗