涉及知识
CSRF漏洞
CSRF漏洞解释、原理
CSRF(Cross-site request forgery)跨站请求伪造,也被称为One Click Attack 或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常 不同,XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比,CSRF攻击性往往不大流行(因此对其进行防范的资源也相对少)和难以防范,所以被认为比XSS更具危险性。
CSRF与XSS的区别:最大的区别就是CSRF没有盗取用户的Cookie,而是直接的利用了用户浏览器的Cookie让用户去执行某个动作。
漏洞简介
跨站请求攻击,简单地说,是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作(如发邮件、发消息、甚至财产操作:转账、购买商品等)。由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份认证的一个漏洞:简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。
CSRF攻击原理及过程
用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A;
在用户信息用过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送请求到网站A;
用户未退出网站A之前,在同一浏览器中打开一个TAB页访问网站B;
网站B接受到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方站点A;
浏览器在接收到这些攻击性代码后,根据网站B的请求,在用户不知情的情况下携带Cookie信息,向网站A发出请求。网站A并不知道该请求其实是由B发起的,所以会根据用户C的Cookie信息以C的权限处理该请求,导致来自网站B的恶意代码被执行。
CSRF攻击实例

受害者 Bob 在银行有一笔存款,通过对银行的网站发送请求http://bank.example/withdraw?account=bob&amount=1000000&for=bob2可以使Bob把1000000 的存款转到bob2的账号下。通常情况下,该请求发送到网站后,服务器会先验证该请求是否来自一个合法的 session,并且该session 的用户Bob已经成功登陆。
黑客 Mallory 自己在该银行也有账户,他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行:http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob,他不能通过安全认证,因此该请求不会起作用。
这时,Mallory 想到使用CSRF的攻击方式,他先自己做一个网站,在网站中放入如下代码: src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory”,并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时,上述 url 就会从Bob的浏览器发向银行,而这个请求会附带Bob浏览器中的cookie一起发向银行服务器。大多数情况下,该请求会失败,因为他要求Bob的认证信息。但是,如果Bob当时恰巧刚访问他的银行后不久,他的浏览器与银行网站之间的session尚未过期,浏览器的cookie之中含有Bob的认证信息。这时,悲剧发生了,这个url请求就会得到响应,钱将从Bob的账号转移到Mallory的账号,而Bob当时毫不知情。等以后Bob发现账户钱少了,即使他去银行查询日志,他也只能发现确实有一个来自于他本人的合法请求转移了资金,没有任何被攻击的痕迹。而Mallory则可以拿到钱后逍遥法外。
CSRF漏洞检测、案例、防御
漏洞检测
漏洞检测方法
- 发送的数据包是否存在Token值
- 检测CSRF漏洞是一项比较繁琐的工作,最简单的方法就是抓取一个正常请求的数据包,去掉Referer字段后再重新提交,如果该提交还有效,那么基本上可以确定存在CSRF漏洞。
- 随着对CSRF漏洞研究的不断深入,不断涌现出一些专门针对CSRF漏洞检测的工具,若CSRFTester,CSRF Request Builder等。
- Burp抓包右键——Engagement tools——Generate CSRF Poc,测试访问构造页面之后是否的确能修改信息,以此验证

会生成一段测试CSRF是否存在的HTML代码

利用次Poc进行测试,验证CSRF漏洞的存在
1 | <html> |
访问该测试代码

点击按钮后会自动跳转,可见修改成功,验证确实存在CSRF漏洞

漏洞检测点
用户信息修改页面
密码修改处
点赞
转账
注销
删除
防御方案
当用户发送重要的请求时需要输入原始密码
设置随机Token(最有效)
Token是数据包的唯一值,可以理解为是数据包的编号。从本站提交的数据包的Token值和从跨站提交的数据包的Token值不同,只需验证Token值是否是本站数据包的Token,即通过Token值验证该数据包是否是从本站发出,也是一种同源策略,检测来源。
检验referer来源,请求时判断请求链接是否为当前管理员正在使用的页面(管理员在编辑文章,黑客发来恶意的修改密码链接,因为修改密码页面管理员并没有在操作,所以攻击失败),但是可以通过抓包修改数据包的Referer值来绕过(不安全)
设置验证码
限制请求方式只能为POST
漏洞条件
被害用户已经完成身份认证
新请求的提交不需要重新身份认证或确认机制
攻击者必须了解Web APP请求的参数构造
引诱用户触发攻击的指令(社工)
SSRF漏洞

SSRF漏洞解释,原理等
SSRF(Server-Side Request Forgery:服务器端请求伪造)是一种由攻击者构造形成并由服务端发起恶意请求的一个安全漏洞。正是因为恶意请求由服务端发起,而服务端能够请求到与自身相连而与外网隔绝的内部网络系统,所以一般情况下,SSRF的攻击目标是攻击者无法直接访问的内网系统。
漏洞原理
SSRF漏洞的形成大多是由于服务端提供了从其他服务器应用获取数据的功能而没有对目标地址做过滤和限制。 例如,黑客操作服务端从指定URL地址获取网页文本内容,加载指定地址的图片等,利用的就是服务端请求伪造,SSRF漏洞可以利用存在缺陷的WEB应用作为代理攻击远程和本地的服务器。
如下图所示,服务器Ubuntu为WEB服务器,可被攻击者访问,内网中的其他服务器无法被攻击者直接访问。假设服务器Ubuntu中的某个WEB应用存在SSRF漏洞,那我们就可以操作这个WEB服务器去读取本地的文件、探测内网主机存活、探测内网主机端口等,如果借助相关网络协议,我们还可以攻击内网中的Redis、MySql、FastCGI等应用,WEB服务器在整个攻击过程中被作为中间人进行利用。

SSRF漏洞检测,案例,防御等
漏洞点
- 社交分享功能:获取超链接的标题等内容进行显示
- 转码服务:通过URL地址把原地址的网页内容调优使其适合手机屏幕浏览
- 在线翻译:给网址翻译对应网页的内容
- 图片加载/下载:例如富文本编辑器中的点击下载图片到本地、通过URL地址加载或下载图片
- 图片/文章收藏功能:主要其会取URL地址中title以及文本的内容作为显示以求一个好的用具体验
- 云服务厂商:它会远程执行一些命令来判断网站是否存活等,所以如果可以捕获相应的信息,就可以进行ssrf测试
- 网站采集,网站抓取的地方:一些网站会针对你输入的url进行一些信息采集工作
- 数据库内置功能:数据库的比如mongodb的copyDatabase函数
- 邮件系统:比如接收邮件服务器地址
- 编码处理、属性信息处理,文件处理:比如ffpmg,ImageMagick,docx,pdf,xml处理器等
- 未公开的api实现以及其他扩展调用URL的功能:可以利用google语法加上这些关键字去寻找SSRF漏洞。一些的url中的关键字有:share、wap、url、link、src、source、target、u、3g、display、sourceURl、imageURL、domain……
- 从远程服务器请求资源
漏洞检测
各个协议调用探针: http,file,dict,ftp,gopher等
常利用的相关协议
http://:探测内网主机存活、端口开放情况,如http://192.168.64.144/phpmyadmin/
gopher://:发送GET或POST请求;攻击内网应用,如FastCGI、Redis
dict://:泄露安装软件版本信息,查看端口,操作内网redis访问等,如dict://192.168.64.144:3306/info
file://:读取本地文件,如file:///D:/www.txt
ftp://:如探测主机的ftp是否开放:ftp://192.168.64.144:21
漏洞利用
端口扫描,指纹识别,漏洞利用,内网探针等
详细参考:SSRF的利用方式
1、内网访问
使用http协议对内网的Web应用进行访问
1 | ?url=http://127.0.0.1/flag.php |
2、伪协议读取文件
PHP支持的伪协议
1 | file:// — 访问本地文件系统 |
php.ini参数设置
allow_url_fopen:默认值On,允许url里的封装协议访问文件。
allow_url_include:默认值Off,不允许url里的封装协议包含文件。
各协议的利用条件和方法

举例:
1 | ?url=file:///var/www/html/flag.php |
3、端口扫描
在SSRF中,dict协议与http协议可以用来探测内网主机存活与端口开放情况。
1 | ?url=dict://127.0.0.1:8000 |
用burp,在intruder中,将端口设置为变量。使用Simple List扫描常用端口,或者使用NumerList进行枚举。当发现长度不同的数据包时,再用http协议进一步探测。
1 | ?url=http://127.0.0.1:8111 |
4、其他
详细参考:SSRF的利用方式
演示案例
Pikachu—CSRF 案例及Burp检测
虚拟机上搭建Pikachu测试平台,进入CSRF练习模块,物理机访问

CSRF(get)模块登录一个账号(一共有这么些用户vince/allen/kobe/grady/kevin/lucy/lili,密码全部是123456),点击进入信息修改页面,修改后提交时进行抓包,得到修改用户信息时的URL

则修改用户信息时的URL为
1 | http://192.168.137.128/pentest/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=12345678910&add=china&email=kobe%40pikachu.com&submit=submit |
将得到的修改用户信息自定义,插入攻击者构造的页面中
我们构造修改用户信息的URL即payload为
1 | http://192.168.137.128/pentest/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=88888888888&add=Shanghai&email=kobe%40pikachu.com&submit=submit |
插入某个自定义的页面
1 |
|
假设已登录自己账号的用户访问了攻击者构造的上述页面,就会向原网站的服务器提交一个修改用户信息的数据包,从而导致用户信息按照攻击者的意愿进行修改

查看原网站的用户信息,尽管用户没有主动修改,但是由于触发了攻击者的网页,攻击者利用CSRF漏洞,已经被动修改了用户信息

同理可以诱导目标网站添加管理员等
Pikachu—CSRF防御Token测试
无
SSRF—PHP、JAVA漏洞代码协议运用

SSRF—漏洞代码结合某漏洞利用测试
使用以下代码测试一个SSRF漏洞
1 | <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
访问上述页面,提交一个远程图片地址,Web服务器会请求该地址,获得该图片的内容并输出

若提交服务器本地地址,也会返回相关信息,比如提交127.0.0.1:3306,返回数据库版本信息

已知该Web服务器内网存在另一台主机(外网用户不能直接访问),IP为192.168.137.128,向上述提交入口提交192.168.137.128:3306可以查看该内网主机的数据库版本

由此可见,通过SSRF漏洞,可以进行服务器内网主机信息的探测,将存在SSRF漏洞的Web服务器作为跳板,访问到外网不能直接访问的服务器内网主机。
SSRF 实战—图片加载翻译转码等应用说明
无
涉及资源
https://pan.baidu.com/s/1bp96ECJ
SSRF漏洞(原理&绕过姿势):https://www.t00ls.cc/articles-41070.html
1 | <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |