当前位置：首页 > news >正文

CSRF跨站请求伪造（Cross - Site Request Forgery）

news 来源：原创 2025/5/10 10:49:04

前提概要

本文章主要用于分享CSRF跨站请求伪造漏洞基础学习路径，以下是对CSRF跨站请求伪造漏洞的一些个人解析，请大家结合参考其他文章中的相关信息进行归纳和补充。

CSRF跨站请求伪造漏洞描述

CSRF 跨站请求伪造漏洞是攻击者利用用户已登录目标网站的身份，诱导其点击恶意链接或访问恶意网站，使浏览器自动携带用户身份信息向目标网站发送非法请求，导致目标网站执行非用户意愿的操作，如转账、修改密码等，给用户带来信息泄露、账户被盗用等危害。

CSRF跨站请求伪造漏洞原理

CSRF（Cross - Site Request Forgery）跨站请求伪造，也被称为 “One Click Attack” 或者 “Session Riding”，是一种常见的网络安全漏洞，其原理如下：

用户登录信任网站

用户在浏览器中登录一个信任的网站，例如银行网站，并进行身份验证。网站通过验证后，会在用户的浏览器中生成一个会话（Session），通常以 Cookie 的形式存储在用户的浏览器中，用于标识用户的身份和权限。最好应用程序使用会话cookie确定是哪个用户发布了请求，没有其他令牌或机制来跟踪用户会话。

攻击者构造恶意网站

攻击者创建一个恶意的网站，其中包含一些精心构造的请求代码。这些请求代码的目的是模拟用户在信任网站上的操作，例如转账、修改密码等。

没有不可预测的请求参数

执行操作的请求不包含任何值的参数，其值无法确定或猜测。例如，当导致用户更改密码时，如果攻击者需要知道现有密码的值，则该功能并不脆弱。

用户访问恶意网站

用户在登录信任网站的状态下，不小心访问了攻击者构造的恶意网站。由于用户的浏览器中已经存储了信任网站的会话 Cookie，当恶意网站向信任网站发送请求时，浏览器会自动带上这些 Cookie。

恶意请求发送到信任网站

恶意网站利用用户浏览器自动发送 Cookie 的机制，向信任网站发送伪造的请求。信任网站接收到请求后，会根据 Cookie 中的用户身份信息来验证请求的合法性。由于 Cookie 是合法的，信任网站会认为请求是用户本人发起的，从而执行请求中的操作。

CSRF跨站请求伪造风险评级

高风险
用户操作涉及重要敏感信息，如银行转账、修改密码、交易支付等，一旦遭受 CSRF 攻击，会直接导致用户资金损失、账户被盗用等严重后果。
目标网站用户群体广泛，且缺乏有效的 CSRF 防护措施，攻击者易于利用漏洞进行大规模攻击，影响众多用户。

中风险
操作会影响用户的重要业务流程或个人信息，如修改个人资料、订阅重要服务等，虽不会直接造成经济损失，但可能导致用户业务受阻、个人信息泄露等问题，给用户带来较大困扰和潜在风险。
网站具有一定的防护机制，但仍存在可被攻击者利用的薄弱环节，或者部分用户可能因自身安全意识不足而容易受到攻击。

低风险
涉及的操作对用户影响较小，如浏览普通页面、查看公开信息等，即使遭受 CSRF 攻击，也不会对用户造成实质性的损害。
网站有较为完善的 CSRF 防护体系，攻击者很难找到有效的攻击途径，或者攻击场景较为特殊，发生的概率极低。

CSRF跨站请求伪造漏洞检测方法

基于请求头的检测

检查 Referer 字段：正常请求的Referer字段会包含发起请求的页面地址，通过验证Referer是否来自信任的域名，可以初步判断请求的合法性。例如，银行网站的转账页面应该只接受来自银行域名下的请求，若Referer是其他不明网站，则可能是 CSRF 攻击。不过，该方法并不完全可靠，因为攻击者可以通过一些手段伪造Referer字段。
检查 Origin 字段：Origin字段通常表示请求的源站点，它比Referer更不容易被伪造。服务器可以验证Origin是否为信任的来源，如果不是，则拒绝请求。这种方法在现代浏览器中得到了较好的支持，是一种较为有效的 CSRF 检测方式。

基于令牌的检测

同步令牌模式：在用户访问受保护的页面或执行敏感操作时，服务器会生成一个唯一的令牌，并将其嵌入到页面的表单或请求参数中。同时，令牌也会存储在用户的会话中。当用户提交请求时，服务器会验证请求中的令牌与会话中的令牌是否一致。如果不一致，说明请求可能是伪造的，从而拒绝该请求。
双重提交 Cookie 模式：服务器在用户登录或访问特定页面时，会在用户的 Cookie 中设置一个令牌，同时在页面的表单或请求参数中也包含相同的令牌。当用户提交请求时，服务器会对比 Cookie 中的令牌和请求参数中的令牌是否匹配。这种方式利用了浏览器在发送请求时会自动携带 Cookie 的特性，即使攻击者能够获取页面中的令牌，也难以获取用户 Cookie 中的令牌，从而有效防止 CSRF 攻击。

基于用户行为的检测

分析用户操作频率：通过监测用户的操作行为，分析其操作频率是否异常。例如，正常用户在进行转账操作时，通常不会在短时间内频繁进行大量转账。如果检测到某个用户的操作频率明显高于正常水平，可能是遭受了 CSRF 攻击，系统可以暂时限制该用户的操作，并要求用户进行身份验证或进一步确认操作。
识别异常操作模式：建立用户行为模型，学习用户的正常操作模式，如操作时间、操作顺序、使用的设备等。当检测到用户的操作模式与正常模式不符时，如在非工作时间进行大额转账，或者从陌生的设备登录并进行敏感操作，系统会发出警报并进行进一步的安全验证。

基于流量分析的检测

检测异常请求流量：通过分析网络流量，识别出异常的请求模式。例如，突然出现大量来自同一 IP 地址或同一用户的相似请求，且这些请求的目标是执行敏感操作，如同时向多个不同账户进行转账，这可能是 CSRF 攻击的迹象。网络安全设备可以通过设置流量阈值和规则，对异常流量进行拦截和分析。
对比请求特征与已知攻击模式：安全防护系统可以维护一个已知的 CSRF 攻击模式库，其中包含各种常见的攻击特征，如特定的请求参数组合、请求头信息等。通过将实时流量中的请求特征与攻击模式库进行对比，若发现匹配的特征，即可判断可能存在 CSRF 攻击，并采取相应的防护措施。

CSRF跨站请求伪造漏洞危害

账户信息泄露与篡改
个人信息泄露：攻击者可利用漏洞获取用户的个人信息，如姓名、联系方式、身份证号码等，这些信息可能被用于精准诈骗、身份盗窃等犯罪活动。
账户密码修改：攻击者可能通过伪造请求，修改用户的账户密码，使用户失去对自己账户的控制，进而导致账户内的资金或重要数据被盗取。

资金损失
直接转账：在金融类应用中，攻击者可模拟用户发起转账请求，将用户账户内的资金转至自己或其指定的账户，造成用户的直接经济损失。
消费欺诈：攻击者还可能利用漏洞在电商平台等进行虚假消费，下单购买商品或服务，而费用则由被攻击的用户承担。

业务逻辑破坏
恶意注册与垃圾信息发布：攻击者可以利用 CSRF 漏洞，在网站上伪造用户注册请求，创建大量垃圾账号，进而利用这些账号发布广告、恶意评论等垃圾信息，影响网站的正常运营和声誉。
干扰业务流程：在一些业务系统中，如订单处理、审批流程等，攻击者可通过 CSRF 攻击伪造请求，干扰正常的业务流程，导致业务混乱、工作效率降低，甚至可能使企业遭受经济损失。

系统权限滥用
提升用户权限：攻击者可能尝试通过 CSRF 攻击提升普通用户的权限，使其具有管理员或其他高级权限，从而能够对系统进行更广泛的破坏，如删除重要数据、修改系统配置等。
执行系统命令：在某些情况下，攻击者利用 CSRF 漏洞结合其他系统漏洞，可能执行系统命令，控制服务器或获取服务器上的敏感信息，对整个系统的安全造成严重威胁。

CSRF跨站请求伪造漏洞利用

portswigger靶场

1.

2.

CSRF跨站请求伪造漏洞防御措施

使用 CSRF 令牌
原理：在用户访问敏感操作页面时，服务器生成一个唯一的、不可预测的令牌，并将其嵌入到页面的表单或请求参数中，同时在用户会话中也存储该令牌。当用户提交请求时，服务器验证请求中的令牌与会话中的令牌是否一致，一致则处理请求，不一致则拒绝。
示例：在一个银行转账页面中，服务器为每个用户生成一个独特的 CSRF 令牌，用户转账时，令牌会随转账请求一同发送到服务器进行验证。

验证请求来源
检查 Referer 字段：服务器检查请求的Referer字段，确保请求来自合法的源站点。但该方法有局限性，因为Referer字段可被伪造。例如，银行网站只允许来自自身域名的转账请求，若Referer是其他不明网站，可能是 CSRF 攻击。
检查 Origin 字段：Origin字段表示请求的源站点，更难被伪造。服务器验证Origin是否为信任来源，不是则拒绝请求。现代浏览器对该方法支持良好。

设置 SameSite 属性
原理：通过设置Set - Cookie响应头中的SameSite属性，指定 Cookie 的发送规则。SameSite有Strict、Lax和None三个值。
示例：若将 Cookie 的SameSite属性设置为Strict，则只有在同一站点发起的请求才会携带该 Cookie，可有效防止 CSRF 攻击。若设置为Lax，则允许一些安全的跨站请求携带 Cookie，如 GET 请求且符合特定规则的情况。

增加验证码验证
原理：在关键操作（如转账、修改密码等）中，要求用户输入验证码。验证码是用户与服务器交互过程中动态生成的，攻击者难以获取和伪造。
示例：用户在银行网站进行转账时，除了输入账号、金额等信息外，还需输入系统发送到手机或邮箱的验证码，以证明是用户本人在操作。

CSRF跨站请求伪造漏洞相关名词

CSRF（Cross - Site Request Forgery）：即跨站请求伪造，是一种常见的网络安全漏洞，攻击者通过诱导用户在已登录的目标网站上执行非用户本意的操作。
用户会话（User Session）：用户在访问网站时，从登录到退出的整个过程中，服务器为用户创建的一个唯一标识，用于跟踪用户的状态和相关信息。在 CSRF 攻击中，攻击者试图利用用户已有的会话来伪造请求。
令牌（Token）：服务器生成的一个唯一的、不可预测的值，用于验证请求的合法性。在 CSRF 防御中，令牌通常被嵌入到页面的表单或请求参数中，与用户会话中的令牌进行比对，以防止伪造请求。
Referer 字段：是 HTTP 请求头中的一个字段，用于标识请求的来源页面。在 CSRF 检测中，服务器可以通过检查 Referer 字段来判断请求是否来自合法的源站点，但该字段可被攻击者伪造。
Origin 字段：也是 HTTP 请求头中的字段，用于表示请求的源站点。与 Referer 相比，Origin 更不容易被伪造，服务器可以通过验证 Origin 字段来防御 CSRF 攻击。
SameSite 属性：是Set - Cookie响应头中的一个属性，用于指定 Cookie 的发送规则，防止 CSRF 攻击。其取值有Strict、Lax和None，分别表示不同的跨站请求限制策略。
验证码（Verification Code）：是一种在用户与服务器交互过程中动态生成的、用于验证用户身份或操作合法性的代码。在 CSRF 防御中，验证码可以作为一种额外的验证手段，增加攻击者伪造请求的难度。
重放攻击（Replay Attack）：攻击者截获并重复发送合法用户的请求，以达到非法目的。CSRF 攻击与重放攻击有相似之处，都是利用了用户的合法请求，但 CSRF 攻击通常是通过诱导用户在不知情的情况下发起请求，而重放攻击则是直接重复已有的请求。
同源策略（Same - Origin Policy）：是一种浏览器安全策略，用于限制不同源的网页之间进行交互。CSRF 攻击试图突破同源策略，通过诱导用户在已登录的目标网站上执行来自其他源的请求。
中间人攻击（Man - in - the - Middle Attack）：攻击者拦截通信双方的信息，并篡改或窃取其中的内容。在 CSRF 攻击中，攻击者可能会利用中间人攻击的方式来获取用户的请求信息或篡改请求内容。
攻击向量（Attack Vector）：指攻击者利用漏洞进行攻击的途径或方法。在 CSRF 攻击中，攻击向量可能是一封包含恶意链接的电子邮件、一个隐藏在网页中的恶意脚本，或者是一个被攻击者篡改的 URL，用户通过点击这些链接或访问相关网页，就可能触发 CSRF 攻击。
诱骗页面（Phishing Page）：攻击者创建的用于欺骗用户的网页，通常与目标网站的页面外观相似，目的是诱导用户输入敏感信息或执行特定操作，从而触发 CSRF 攻击。例如，攻击者可能会制作一个看似银行登录页面的诱骗页面，用户在上面输入账号密码后，这些信息就会被攻击者获取，同时攻击者可能利用用户登录状态发起 CSRF 请求。
会话固定（Session Fixation）：一种与 CSRF 相关的攻击技术，攻击者事先获取一个用户的会话 ID，然后诱导用户使用该会话 ID 登录系统，从而固定用户的会话。之后，攻击者就可以利用这个固定的会话进行 CSRF 攻击，因为用户在该会话下的操作会被服务器认为是合法的。
双重提交 Cookie（Double Submit Cookie）：一种 CSRF 防御机制，服务器在设置 Cookie 时，同时在页面中嵌入一个与 Cookie 值相同的令牌。当用户提交请求时，服务器验证 Cookie 中的值与请求参数或请求头中的令牌是否一致，以此来判断请求是否合法。这种方法结合了 Cookie 和令牌的验证，增加了 CSRF 攻击的难度。
CSRF Token 生成算法：用于生成 CSRF 令牌的特定算法，要求生成的令牌具有随机性、唯一性和不可预测性，以确保其安全性。常见的算法可能基于加密哈希函数、随机数生成器等，例如使用HMAC - SHA256算法结合用户会话信息和一个密钥来生成令牌。
CORS（Cross - Origin Resource Sharing）：跨源资源共享，是一种机制，允许网页向不同源的服务器请求资源。虽然 CORS 主要用于解决跨域资源访问的问题，但在 CSRF 攻击场景中，如果 CORS 配置不当，可能会被攻击者利用，导致 CSRF 攻击更容易实施。例如，错误地允许来自任意源的请求访问敏感资源，就可能为 CSRF 攻击打开方便之门。
Web 应用防火墙（Web Application Firewall，WAF）：一种专门用于保护 Web 应用程序免受各种攻击的安全设备或软件。WAF 可以检测和阻止 CSRF 攻击，通过分析 HTTP 请求的特征、检查请求中的令牌或其他相关参数，以及识别异常的请求模式等来识别和防范 CSRF 攻击。
HTTPOnly Cookie：一种设置了HTTPOnly属性的 Cookie，该属性使得 Cookie 只能通过 HTTP 协议访问，而不能通过客户端脚本（如 JavaScript）访问。这有助于防止攻击者通过脚本窃取用户的 Cookie，从而在一定程度上减轻 CSRF 攻击的风险，因为攻击者难以获取到用于验证用户身份的 Cookie 信息。