比较简单的洞,其实在CTFshow平台上,这部分题目直接放在xss了,当然这部分和XSS也非常相似,都是利用了HTML和JS
CSRF是什么
跨站请求伪造,允许攻击者诱导用户执行他们不愿意执行的操作。允许攻击者部分规避同源策略,该策略旨在防止不同网站之间相互干扰。
简言之,冒充用户,做一些恶意请求,伪装用户进行恶意操作。
CSRF攻击的影响
在成功的CSRF攻击中,攻击者会导致受害者用户无意执行某项操作。例如,改受害用户的电子邮箱地址、改受害用户的头像、个性签名,甚至是可以修改他的密码进行资金转账。像CTFshow_XSS后边几个题就是如此。如果受害用户是admin,那么能进行的操作可能更多。
CSRF如何工作
CSRF要想存在,必须具备三个关键条件,所以说这种洞也是很少。
1、网站中存在用户可登录的地方,如果就是个纯静态的网站,连用户登录点都没有,那一切都是空谈。
2、执行该操作时涉及发出一个或者多个HTTP请求,并且网站仅依赖cookie来识别发出请求的用户。没有其他机制可用于追踪会话或验证用户请求。而且这个cookie必须要能利用到其他站点,因为我们要跨站,如果cookie不能跟走,那也是没什么用的,比如说httponly和SameSite都会阻碍我们的CSRF和XSS
3、执行CSRF操作的请求不包含攻击者无法确定或猜测其值的任何参数。例如,当导致用户更改密码时,需要知道现有的密码,那么自然是无法实现。
例如,假设一个网站包含一个允许用户更改自己账户上的电子邮箱地址的功能。用户执行此操作时候。会发出如下HTTP请求:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfEemail=charmersix@gmail.com
这个例子就符合上述三个条件,
- 该网站存在登陆点,至少可以用Email登录
- 就这一个Cookie牵连着
- 没有其他因素影响攻击者
那么就可以开始攻击他了,构建一个HTML网页,like this
1 | <html> |
那么你一定好奇,这些都要自己写吗,可不可以一键日卫星,当然可以。
这个下面会结合靶场具体讲,这里只是举个小🌰而已
那么这时候受害者访问攻击者的网页,他们在存在csrf漏洞的网站的邮箱就会改变成攻击者的邮箱
pwned@evil-user.net
小tips
尽管csrf通常被描述为与基于cookie的会话处理相关,但它也出现在应用程序自动将一些用户凭据添加到请求的其他上下文中,例如http基本身份验证和基于证书的身份验证。
构建CSRF攻击
从上边🌰中能看出,我们自己去手动写CSRF漏洞利用的HTML可能会比较麻烦,特别是所需的请求包含大量参数或请求中有其他麻烦的情况下。构建CSRF一键日🛰的方法就是使用burp suite内置的CSRF PoC 生成器
这边我们来一个简单的靶场,主要是说一下bp的使用。
靶场我们选用的是burp官网的靶场csrf第二题
我们抓包改邮箱看一下,会发现这里边绑定了cookie和一个token也就是内个CSRF=
然后我们看一下这个cookie有什么规律,再改一下
经过测试,我们发现,把传输方式改成GET,token就没什么卵用了
就可以生成一个poc
在这个选项里可以勾选自动提交
当然要自动提交了,再让受害者去点击提交,不是添麻烦嘛
我们直接复制下来html
1 | <html> |
这里我们要把邮箱改成攻击者的邮箱
我们来到这个exploit server,把这坨HTML复制到框里
然后点击漏洞利用
CSRF漏洞利用
CSRF与XSS的原理基本相同。通常,攻击者会将恶意HTML放置到他们控制的网站上,然后诱导受害者访问该网站。这可以 通过电子邮件或社交媒体消息向用户提供网站链接来完成。或者如果攻击被放置在一个流行的网站中(例如,某用户评论区),他们就等着有用户访问恶意网站。
请注意,一些简单的CSRF漏洞利用使用GET方式,并且可以在易受攻击的网站上使用单个URL完全自包含。这种情况下,攻击者可能不需要外部站点,并且可以直接向受害者提供易受攻击上的恶意URL.在前面的例子中,如果可以使用GET方法执行更改电子邮箱地址的请求,那么自包含攻击如下所示:
1 | <img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net"> |
防止CSRF攻击
防御CSRF攻击的最可靠方法是在相关请求中包含CSRF token。
并且token要满足下面三个条件:
- 对于一般的token,值是不可预测的。
- session绑定到用户
- 执行相关操作之前,token一直能经过验证
最常见的防御就是samesite cookie
常见的CSRF漏洞
CSRF一般出现在邮箱修改,转账修改
最有趣的CSRF漏洞由于token验证错误引起。
在前面的示例中,假设application现在在更改用户电子邮箱的请求中包含一个CSRFtoken:
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 68
Cookie: session=2yQIDcpia41WrATfjPqvm9tOkDvkMvLmcsrf=WfF1szMUHhiokx9AHFply5L2xAOfjRkE&email=wiener@normal-user.com
这种看起来可以防御CSRF攻击,因为它不具备CSRF存在的条件:网站不仅仅依赖于cookie进行会话处理,并且请求包含一个攻击者无法确定其值的参数。然而,有多种方法可以打破防御,所以还是有被CSRF攻击的可能。
还有很多具体的情况,bp靶场里也是有的。
CSRF还是很简单的,原理也比较好理解,具体绕过始终也离不开cookie,token,请求头之类的。
- Post title: Web_CSRF
- Create time: 2022-08-26 00:00:00
- Post link: 2022/08/26/CSRF/
- Copyright notice: All articles in this blog are licensed under BY-NC-SA unless stating additionally.