以下为CSRF中token篇
第四关-token未与session绑定
实验的名字为
Lab: CSRF where token is not tied to user session
大概意思就是说当前token并未与当前用户的session绑定在一起
![](https://i-blog.csdnimg.cn/blog_migrate/5e0e257c4649f4338db87abe72d1a86d.png)
给了两个账号,就是来在本地验证,token并未与session绑定
现在登陆的是A用户
先登录一个用户,使用bp抓取修改邮箱的包,将其发送到repeter板块。
![](https://i-blog.csdnimg.cn/blog_migrate/44e1f8d8048a159cb8672f9f102caf4a.png)
在第一次在repeter中发包,通过返回可以看出已经成功修改了
![](https://i-blog.csdnimg.cn/blog_migrate/43879d82271c88aadb8ce2b5aaaa968c.png)
如果再次发送会发现invalid token。
![](https://i-blog.csdnimg.cn/blog_migrate/d1e768884d53a94b8f0bb67c247d3412.png)
此时再从原来的页面中,刷新一下,拿到一个新的还没用过的token,将其放在repeter中替换token。
![](https://i-blog.csdnimg.cn/blog_migrate/6445f8ca3f26ae183bab7d9a5e9d288d.png)
此时会发现已经修改成功。、
![](https://i-blog.csdnimg.cn/blog_migrate/119f7b04de3000e7f2e98a3e377521d9.png)
此时应该就能看出来,其实token是在变化的。
只要一个token用过一次,那么token就作废了。
现在登录B用户
拿到一个A用户一个还没用过的token,
抓取一个B用户修改邮箱的包,将其token更改为A用户的token
此时的情况是
B用户+A用户token
![](https://i-blog.csdnimg.cn/blog_migrate/176c7a5a41bc08dbdc84ba890d6d5386.png)
发现竟然成功了。此时就能推断出,token与用户的session无关。
那么我们也可以通过再获取一个A用户的新鲜token去pass this lab
再repeter中拿到CSRF的POC
按照图中点即可,实现一种功能,即打开网站即可提交表单,修改邮箱
![](https://i-blog.csdnimg.cn/blog_migrate/94df9e040f93a685b317f7b61eee4002.png)
将生成的代码放到下面的框框中,点击提交,即可通过
![](https://i-blog.csdnimg.cn/blog_migrate/a4bdba72491072bbc69ef4719508f8dd.png)
第五关-token绑定了非对话session
原文题目
Lab: CSRF where token is tied to non-session cookie
分析
CSRF的三个相关条件
![](https://i-blog.csdnimg.cn/blog_migrate/a2e973a577038f5db38b2bfb112a7d4c.png)
抓一个修改邮箱地址的包。
可以看到有token,
接下来就是对token的分析
![](https://i-blog.csdnimg.cn/blog_migrate/c01a579f1df6c9d4fd2e702098b7ff09.png)
再repeter中发送了两下,发现token是可以重复利用的。
并且又发现 在cookie中有一个csrfKey的东西,猜测是token与它绑定着。
接下来就要分析
:::success
1、检查token与csrfKey Cokkies的关系
提交一个错误的CSRFtoken()
提交一个来自其他用户CSRFtoken (判断token与CSRFKey Cookeies的关系。是否绑定在一起呢)
:::
分析一
提交一个错误的token会发现,invalid token,
未成功
![](https://i-blog.csdnimg.cn/blog_migrate/1adde564df926a12738875f60b9c7362.png)
在Chrome中新建私密空间,登录B用户,获取到token后替换当前Repeter中的token再次发送,会发现invalid
未成功。
![](https://i-blog.csdnimg.cn/blog_migrate/6791ce04109a4648343cb5bff0f3e9f1.png)
我们拿到一个真实可用的token去测试,发现还是不行的话。此时可以推断出token与Cookie中的csrfKey绑定着呢
分析二
:::success
1、检查token与csrfKey Cokkies的关系
提交一个错误的CSRFtoken()
提交一个来自其他用户CSRFtoken (判断token与CSRFKey Cookeies的关系。是否绑定在一起呢)
2、将A用户的Cookies csrfKey和token 全部替换为B用户的
:::
替换完后会发现。竟然成功修改了。
![](https://i-blog.csdnimg.cn/blog_migrate/bc8084f52b3d6755ad86024694a70212.png)
此时完全推断出Cookie csrfKey 与 token完全绑定着呢。
现在我们的整体思路就是
1、在被攻击的浏览器中插入一个http Cookie:csrfKey 。它的值就是我们已知A用户的就行。
2、将csrfpoc发送给被攻击者,即可成功。
注意:csrfKey和token 必须为一对
修改Cookie
现在已经知道了,csrfKey和token是一对的,所以我们要向被攻击者的浏览器去修改csrfkey的Cookie。
通过查询功能可以看出,当查询一个东西时,会向当前页面插入一个cookie,此时是否可以通过修改抓包,修改包
将我们的csrfKey Cookie插入到浏览器中呢。
![](https://i-blog.csdnimg.cn/blog_migrate/59835bc989624ef03bf7a2da873d2584.png)
通过抓包、可以看出在 search后的hat和Set-Cookie彷佛有着联系。
![](https://i-blog.csdnimg.cn/blog_migrate/4352d9bfb5deb539983a1c8610d6d26a.png)
通过这段payload
/?search=hat%0b%0aSet-Cookie:%20scrfKey=值
即可成功修改csrfKey的值
![](https://i-blog.csdnimg.cn/blog_migrate/ef8466611ba6bf3024b43875d8e912dc.png)
此时要理清的是,这能运行是因为我们执行了一个url进行了一段数据的查询,修改了一段url使其结果朝着我们想要的方向发展。
只要访问这段连接即可修改cookie
:::success
:::
攻击
再抓取一个修改邮箱的包,设置poc
将token更改为A用户我们已知的。
在后面加入这段payload,加载一个图片,图片的连接,就是我们上面修改cookie csrf的连接。然后此时肯定是不对的,是报错,然后后面的onerror就是接受这个错误的,如果错的话,会执行这段代码,自动提交表单,修改邮箱,
οnerrοr="document.forms[0].submit()">
后面必须得加上这个黑色背景那段,要不然不会成功
![](https://i-blog.csdnimg.cn/blog_migrate/93cb722614566dc5c947d73b31dd4a60.png)
提交完后即可成功pass
![](https://i-blog.csdnimg.cn/blog_migrate/93c751c5084556feaa35d9498cbceb8d.png)
第六关-双重提交仿CSRF
原文题目
CSRF token is simply duplicated in a cookie
先抓取一个提交修改邮箱的包,发现cookie中csrf和url中参数csrf值相同
![](https://i-blog.csdnimg.cn/blog_migrate/f49a8d5500c3a3f6d1d6f430598382f8.png)
:::success
这里提到了一个double submit防范方式,其具体原理为:
Web应用不维护已发出令牌的任何服务器端记录,而是在一个cookie和一个请求参数中复制每个令牌,在验证后续请求时,应用程序只需验证在请求参数中提交的令牌是否与在cookie中提交的值匹配,这样一来就避免了任何服务器端状态的需要,因此也是一种不错的实现方式。
:::
尝试去删除url参数中csrf最后一个字符。
发现invalid token
![](https://i-blog.csdnimg.cn/blog_migrate/1941674d6b71ff1dc0b5dd996bd1bbc8.png)
将cookie中csrf的最后一个字符也删除,使cookie中和url中都相同。此时发现已经可以修改邮箱了。
![](https://i-blog.csdnimg.cn/blog_migrate/baef017e05930a12992160e9c8235dca.png)
此时的思路和上题差不多。
使用http cookie注入,向目标浏览器中注入一个已知的cookie使其与token相同。
也是使用搜索栏中,插入cookie
![](https://i-blog.csdnimg.cn/blog_migrate/314afb5a6884aaf8f9c0d3a8dcb31022.png)
pass
![](https://i-blog.csdnimg.cn/blog_migrate/1c057a2a393445320f826bf11248c5e0.png)
以下为Cookie篇
第七关-绕过SameSite Lax类型-通过更改提交Method
:::success
当SameSite类型为Lax的话,
原理可以看一下这个视频
如果是Lax的话在跨站请求中获取Cookie的话必须满足以下两个条件
The request uses the GET method. (必须为GET请求)
The request resulted from a top-level navigation by the user, such as clicking on a link.(必须为点击事件,可伪造)
例如,这意味着跨站POST请求中不会包含cookie。由于POST请求通常用于执行修改数据或状态的操作(至少根据最佳实践),它们更有可能成为CSRF攻击的目标。
同样,cookie也不会包含在后台请求中,比如那些由脚本、iframe发起的请求,或者对图像和其他资源的引用。
:::
原题
SameSite Lax bypass via method override
通过分析可以看出,并未加入token
![](https://i-blog.csdnimg.cn/blog_migrate/76677a639db87e13f7348caa682e54ad.png)
在这里看出SameSite的并未为None,所以为Lax,Chrome默认给SameSite设置的就是Lax。
![](https://i-blog.csdnimg.cn/blog_migrate/28101cf311b157f6fc2a54164c2cb3d5.png)
通过多次尝试去发送请求,发现都可以成功修改。
![](https://i-blog.csdnimg.cn/blog_migrate/fbbaab02b1f9fe8b381b9a79733d4ea6.png)
现在我们的思路就是,还是和之前差不多,要整一个POC给受害者。在本地测试一下
生成一个链接,在网站中打开,如果此时我们的邮箱被改了,那么可以证明在受害者中也将被修改。
![](https://i-blog.csdnimg.cn/blog_migrate/4dd4c69d282180a56a9857b0c00c807d.png)
但是此时我们发现打开链接后,出现的是登录界面。这是为什么呢。
想起前面的Lax,可以分析出是因为我们点击了一个链接,该请求是一个POST请求,在Lax中POST请求不会携带cookie。也就会出现一个登录页面,现在这个页面不认识我们了。
![](https://i-blog.csdnimg.cn/blog_migrate/011bb604d2ca823f544d041728510982.png)
现在的问题就是如何绕过,那个POST请求,修改为GET请求如何
![](https://i-blog.csdnimg.cn/blog_migrate/3bad3f60f5a914ec6bf1ed9614276853.png)
它显示了方法不允许。这就需要绕过
![](https://i-blog.csdnimg.cn/blog_migrate/ec73acce57a87e3d5a0b5eead2d81d1e.png)
我们只需要在GET请求参数后加入一个_method=POST即可。
浏览器会以为我们是POST请求。
![](https://i-blog.csdnimg.cn/blog_migrate/b620dc1e24953d455ea96d59f590e74f.png)
此时在生成一个POC。
![](https://i-blog.csdnimg.cn/blog_migrate/b02fc1b9cb83ae9243b7a66383b5d80d.png)
即可pass
![](https://i-blog.csdnimg.cn/blog_migrate/7075d8d10da07a3eb060e3c9737e8af6.png)
第八关-绕过SameCookie Strict类型-通过重定向
原题
Lab: SameSite Strict bypass via client-side redirect
If a cookie is set with the SameSite=Strict attribute, browsers won't include it in any cross-site requests. You may be able to get around this limitation if you can find a gadget that results in a secondary request within the same site.
One possible gadget is a client-side redirect that dynamically constructs the redirection target using attacker-controllable input like URL parameters. For some examples, see our materials on DOM-based open redirection.
As far as browsers are concerned, these client-side redirects aren't really redirects at all; the resulting request is just treated as an ordinary, standalone request. Most importantly, this is a same-site request and, as such, will include all cookies related to the site, regardless of any restrictions that are in place.
If you can manipulate this gadget to elicit a malicious secondary request, this can enable you to bypass any SameSite cookie restrictions completely.
翻译后 --》
在strict中,任何跨站请求都将不会包含Cookie,但是如果能找到一个在同站点中导致二次请求的方法,那么即可绕过。
该方法就是利用重定向,重定向包含了该网站的所有Cookie,此时即可执行一些恶意操作。重定向就相当于是简单、独立的请求,在同一站点会包含所有Cookie
首先我们先登录一个ID,然后执行修改邮箱操作并抓取一个包,通过将该包转换为GET请求,再次发送即可发现成功修改。
此时我们可以尝试生成一个POC,测试一下。
![](https://i-blog.csdnimg.cn/blog_migrate/7abf186b66fba5627e1a799eb85c63a6.png)
使用链接的方式,这样最能接近受害者角度。
![](https://i-blog.csdnimg.cn/blog_migrate/d4959b9a57035b97d6f928e91875bdda.png)
当我们将链接在网页中打开时,点击submit时,会发现已经需要重新登录了。
这是因为SameCookie的类型时Strict的原因。
当我们点击submit的时候,其实已经算是跨站请求了。自然不会包含Cookie。
![](https://i-blog.csdnimg.cn/blog_migrate/d6dcdffcd78a111af1d67cb5c565ee37.png)
![](https://i-blog.csdnimg.cn/blog_migrate/84faece6b9a164f18de09b03a2cae0ec.png)
所以此时我们需要一种方法,来绕过。此方法就是寻找一个重定向的页面。
当我们去主页,点开一个博客,进行评论。
![](https://i-blog.csdnimg.cn/blog_migrate/7ae9a5f2484c60dacbd6886ed2c52c28.png)
![](https://i-blog.csdnimg.cn/blog_migrate/ca6a4438ecefd6b1e94099b9f980bd54.png)
评论完后,此时会发现有一个重定向的页面。
![](https://i-blog.csdnimg.cn/blog_migrate/e505ca5053604ad1f777c22fc3992db6.png)
然后就回到该博客了。
![](https://i-blog.csdnimg.cn/blog_migrate/867b84561c648e230543d63d8ff40ad3.png)
通过查询http历史,可以看到确实在提交评论后,会有一个重定向的页面,该页面的返回源代中看到了重定向的JS代码。
![](https://i-blog.csdnimg.cn/blog_migrate/24ce9a6ba1821937f6fe90689190014f.png)
在targe中找到了js路径
![](https://i-blog.csdnimg.cn/blog_migrate/62b1d4a85f77ce155e7db5ea6ac8689b.png)
访问,即可找到源码,通过分析源码可知
传递了一个postId,再用
window.location = blogPath + '/' + postId;
这段代码重定向。
![](https://i-blog.csdnimg.cn/blog_migrate/8f45d268b6a876460e88b0048c7022f2.png)
postId就是这个数据包发送的,我们可以利用这个数据。构造CSRF
通过postId的值,为目录遍历的代码即可
![](https://i-blog.csdnimg.cn/blog_migrate/76f5afe41820bb7185609e7d8af22777.png)
postId=../my-account
这样即可返回到自己账户页面。
前面已经知道了在修改邮箱的时候可以改为GET请求。
所以payload进一步修改
postId=../my-account/change-email?email=test%40qq.com&submit=1
加上../返回上层目录,是因为在JS代码中,有一个/
所以我们必须要返回的网站根目录所以要加上../
![](https://i-blog.csdnimg.cn/blog_migrate/ed26a8a3921450effafe9e44e9c9680b.png)
完整的payload如下,
记得要将&进行url编码
我们将原本修改邮箱的数据包中传递参数改一下。
![](https://i-blog.csdnimg.cn/blog_migrate/dc4ec8e027a90acbcb46200974f65a01.png)
然后将生成poc
![](https://i-blog.csdnimg.cn/blog_migrate/e66245dbf0cddbd6f74c2a302469824d.png)
复制代码到地方即可pass
![](https://i-blog.csdnimg.cn/blog_migrate/44e2d55551aa6b3ab71681c30f3e0055.png)
以下为Referer篇
第九关-删除Referer
有些应用程序会在请求中验证Referer首部,但如果该首部被忽略,则跳过验证。
在这种情况下,攻击者可以设计CSRF漏洞攻击程序,使受害者用户的浏览器在产生的请求中删除Referer首部。实现这一目标的方法有很多种,但最简单的是在发起CSRF攻击的HTML页面中使用META标签:
<meta name="referrer" content="never">
通过抓取一个修改邮箱的数据包,放入repeter板块中,反复发送。
可发现可以不断修改,此时就可以尝试生成poc
![](https://i-blog.csdnimg.cn/blog_migrate/3f0ed2f26ec967e403ba892094c63748.png)
生成一个poc在本地中打开。
![](https://i-blog.csdnimg.cn/blog_migrate/866cfab3b079d1859256f3999d978854.png)
referer不正确。这是因为在生成的页面中点击一下submit即可发送一个url请求,此时的请求会自带referer。而此时的referer来自于burpsuite生成的网站,不是同域名,所以会显示Invalid referer header。
![](https://i-blog.csdnimg.cn/blog_migrate/f76f14e17411538d325c76938a6d8600.png)
在数据包中修改一下referer会发现,显示invalid referer。
此时就能准确判断出和referer有关。
![](https://i-blog.csdnimg.cn/blog_migrate/6ac3b950c5460e360102a8c51660619d.png)
将referer删除即可成功
![](https://i-blog.csdnimg.cn/blog_migrate/44283e8995b4ab8546f0966e706eca17.png)
但是在生成poc中即使将referer删除掉,在点击submit时也会自带referer。
此时可以在poc中加上
referrer别打错了
![](https://i-blog.csdnimg.cn/blog_migrate/e621596f0435a0978237d77a9ba353f8.png)
复制代码到exploit server
pass
![](https://i-blog.csdnimg.cn/blog_migrate/56d50965c9c583263658dad510c739b2.png)
第十关-绕过判断不严谨Referer
在本次实验中我们将绕过一些,只要Referer中的域名存在与当前站点的域名相同的即可。
首先先抓取一个数据包。
![](https://i-blog.csdnimg.cn/blog_migrate/9aca994f0071001c06b037eaeaefe4e2.png)
生成一个poc,使用链接测试,会发现Invalid referer
![](https://i-blog.csdnimg.cn/blog_migrate/52f9a2ff44abb22f51e44dbe3e8459ac.png)
通过查看历史记录,发现Referer来自burpsuite。
![](https://i-blog.csdnimg.cn/blog_migrate/942c19e3e157ba52596a405e1b7d036e.png)
此时考虑上一个实验的方法。
删除referer后,还是不行
![](https://i-blog.csdnimg.cn/blog_migrate/65f47903cec00479002225c16f49d9dc.png)
此时我们在原本的域名前加上一段我们自己设置的域名。
将原本的域名以参数形式传递,发先竟然成功了。
![](https://i-blog.csdnimg.cn/blog_migrate/d5216aa6f8209c652c93b9db697f72aa.png)
我们在poc中插入一段域名
![](https://i-blog.csdnimg.cn/blog_migrate/f40d2122401c60ee28bc6991812af165.png)
在复制代码到Exploit server中 要在Head中加入
Referrer-Policy: unsafe-url
原因是
如果存储漏洞并通过单击“查看漏洞”进行测试,您可能会再次遇到“无效的 Referer 标头”错误。这是因为许多浏览器现在默认从 Referer 标头中删除查询字符串作为安全措施。要覆盖此行为并确保完整的 URL 包含在请求中,请返回漏洞利用服务器并将以下标头添加到“Head”部分,[请注意,与普通的 Referer 标头不同,在这种情况下,“referrer”一词必须拼写正确。]
![](https://i-blog.csdnimg.cn/blog_migrate/fc4d585e22835c5d5db26447e44ec686.png)
即可pass