CSRF
原理
跨站请求攻击,简单地说,是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作(如发邮件、发消息、甚至财产操作:转账、购买商品等)。由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份认证的一个漏洞:简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。
CSRF与XSS的区别:最大的区别就是CSRF没有盗取用户的Cookie,而是直接的利用了用户浏览器的Cookie让用户去执行某个动作。
产生条件
- 被害用户已经完成身份认证
- 新请求的提交不需要重新身份认证或确认机制
- 攻击者必须了解Web APP请求的参数构造
- 引诱用户触发攻击的指令(社工)
危害
利用csrf,攻击者可以盗用你的身份,以你的名义发送恶意请求。 你的名义发送邮件、发消息,盗取你的账号,添加系统管理员,甚至于购买商品、虚拟货币转账等。
分类
无
检测
检测方法
- 发送数据包是否存在Token值
- 去掉数据包的Referer字段后重新提交,看是否能有效提交——同源策略
- CSRF专用检测工具:CSRFTester,CSRF Request Builde
- Burp在数据包页面右键生成检测CSRF的Poc
检测位置
- 用户信息修改页
- 密码修改页面
- 转账页面
- 注销页面
- 删除页面
利用
利用目的
盗取用户身份,以用户的名义发送请求
攻击过程
用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A;
在用户信息用过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送请求到网站A;
用户未退出网站A之前,在同一浏览器中打开一个TAB页访问网站B;
网站B接受到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方站点A;
浏览器在接收到这些攻击性代码后,根据网站B的请求,在用户不知情的情况下携带Cookie信息,向网站A发出请求。网站A并不知道该请求其实是由B发起的,所以会根据用户C的Cookie信息以C的权限处理该请求,导致来自网站B的恶意代码被执行。
受害者 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则可以拿到钱后逍遥法外。
修复与防御方案
当用户发送重要的请求时需要输入原始密码
设置随机Token(最有效)
Token是数据包的唯一值,可以理解为是数据包的编号。从本站提交的数据包的Token值和从跨站提交的数据包的Token值不同,只需验证Token值是否是本站数据包的Token,即通过Token值验证该数据包是否是从本站发出,也是一种同源策略,检测来源。
检验referer来源,请求时判断请求链接是否为当前管理员正在使用的页面(管理员在编辑文章,黑客发来恶意的修改密码链接,因为修改密码页面管理员并没有在操作,所以攻击失败),但是可以通过抓包修改数据包的Referer值来绕过(不安全)
设置验证码
限制请求方式只能为POST
SSRF
原理
SSRF(Server-Side Request Forgery:服务器端请求伪造)是一种由攻击者构造形成并由服务端发起恶意请求的一个安全漏洞。正是因为恶意请求由服务端发起,而服务端能够请求到与自身相连而与外网隔绝的内部网络系统,所以一般情况下,SSRF的攻击目标是攻击者无法直接访问的内网系统。
产生条件
SSRF漏洞的形成大多是由于服务端提供了从其他服务器应用获取数据的功能而没有对目标地址做过滤和限制。
例如,黑客操作服务端从指定URL地址获取网页文本内容,加载指定地址的图片等,利用的就是服务端请求伪造,SSRF漏洞可以利用存在缺陷的WEB应用作为代理攻击远程和本地的服务器。
危害
穿透了网络边界,但具体能做到哪种程度还需要根据业务环境来判断
分类
无
检测
检测方法
各个协议调用探针: 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
检测位置
- 社交分享功能:获取超链接的标题等内容进行显示
- 转码服务:通过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……
- 从远程服务器请求资源
利用
利用目的
利用过程
端口扫描,指纹识别,漏洞利用,内网探针等
详细参考: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的利用方式
修复与防御方案
略