SSRF和CSRF漏洞(包含SSRF+Redis未授权getshell)
slug
series-status
status
summary
date
series
type
password
icon
tags
category
SSRF
简介
Server-Side Request Forgery (SSRF) 是一种常见的 Web 应用安全漏洞,影响到服务器端的请求。它允许攻击者通过构造恶意请求,诱导服务器执行非法请求。
通常,SSRF 漏洞发生在当 Web 应用程序允许用户提交 URL 作为请求参数,而应用程序本身并未对这些请求进行正确的验证和过滤。因此,攻击者可以构造恶意请求,以诱导服务器访问内部网络上的敏感资源,或者诱导服务器执行其他类型的非法请求,如端口扫描、DNS 解析攻击等。
为了预防 SSRF 漏洞,开发人员需要对所有请求参数进行严格的验证和过滤,以确保它们不会被恶意攻击者误导执行非法请求。此外,开发人员还应该考虑在 Web 应用程序中使用安全机制,如访问控制和身份验证,来限制对敏感资源的访问。
Pikachu靶场复现
环境
- pikachu靶场
复现
直接打开pikachu靶场的ssrf模块

可以看到这里的url参数部分是一个外部地址,我们可以任意输入内容,我们尝试输入一个我们的npm端口

可以看到这里可以通过这个ssrf漏洞访问到我们内网的其他服务。
当然,和我们的xxe漏洞一样,我们也可以在这个部分通过file协议访问本地文件

还可以通过dict协议查看不同服务的版本信息

SSRF+Redis -> getshell
环境
- vulhub/weblogic ssrf漏洞
- vulfocus/redis-cnvd_2015_07557:latest


将两个镜像全部导入vulfocus

Weblogic-SSRF
我们先启动weblogic容器

漏洞URI
- 尝试探测本机7001端口

说明本机7001端口是开放的,只是返回404而已。
- 尝试探测7002端口

说明7002端口未开放,无法连接。
ssrf + redis
启动redis容器

借助portainer查看容器ip

利用ssrf探测redis

发现redis服务存在。
利用ssrf发送三条redis命令,将反弹shell的脚本写入
/etc/crontab
进行URL编码(注意换行要手动修改为%0D%0A)
在另一台服务器开启监听

攻击URI
其中,operator=http://172.17.0.4:6379/ 这个是redis的IP和端口
最后一个ip:192.168.0.100%2F2333 这个是要反弹shell的主机ip和端口
按说这里应该是没问题的,但是最后的反弹shell无论是虚拟机环境还是服务器都没弹成功,如果有大佬看到了这篇文章希望可以帮我答疑解惑一下~
所以这里就先将我的参考文章贴在这里,大家也可以自己尝试一下
参考文章1:http://t.csdn.cn/aZrbq
CSRF
简介
Cross-Site Request Forgery (CSRF) 是一种常见的 Web 应用安全漏洞,影响到客户端请求。它允许攻击者通过在受害者的浏览器中构造恶意请求,诱导服务器执行非法操作。
CSRF 漏洞通常发生在用户已登录到 Web 应用程序,并保持了活动会话。攻击者可以通过在其他网站中嵌入恶意代码,或通过发送邮件或即时通讯消息,诱导受害者点击恶意链接,从而向 Web 应用程序发送非法请求。
为了预防 CSRF 漏洞,开发人员需要在 Web 应用程序中使用验证令牌 (token) 来识别真实的请求。这些令牌是唯一的、不可预测的字符串,并在客户端和服务器端保存。每次请求都必须包含这些令牌,以确保请求是合法的。此外,开发人员还可以考虑在 Web 应用程序中使用 HTTPS 协议,以确保请求数据在传输过程中加密。
Pikachu靶场复现
打开靶场csrf模块

根据提示选一个账号登录

修改信息,并提交


burp抓取修改信息的数据包

放到repeater并修改一下sex信息

利用burp的
csrf poc
模块,生成csrf payload
点击下方的
test in browser

复制以下地址到已登录pikachu的浏览器打开


点击submit,可以看到性别已经修改了

后续的post模块也一样

但是由于token模块它新增了一个每次请求随机生成的token,因此无法再重新进行csrf漏洞利用了。
Loading...