后台SSRF风险

[LTLTLXEY]

• 由于感觉危害有限，所以直接开了issue
• 简单来说就是在后台有一个testbturl函数，bt_surl可控，php的curl_init支持一些较为危险的协议，比如file://、gopher://、dict://等等，至于拼接上的字符串 api/SetupCount可以用锚点标签等方法让curl_init忽略掉

<?php
// ......
public function testbturl(){
        $bt_type = input('post.bt_type/d');
        
        if($bt_type == 1){
            $bt_surl = input('post.bt_surl');
            if(!$bt_surl)return json(['code'=>-1, 'msg'=>'参数不能为空']);
            $res = get_curl($bt_surl . 'api/SetupCount');
            if(strpos($res, 'ok')!==false){
                return json(['code'=>0, 'msg'=>'第三方云端连接测试成功！']);
            }else{
                return json(['code'=>-1, 'msg'=>'第三方云端连接测试失败']);
            }
        }
// ......
?>

• 这里可能造成无回显SSRF漏洞CWE-918
• 比如用gopher攻击内网未授权的mysql，或者 已知密码/未授权 的redis服务
• 图中展示为修改redis的test键值

• 建议限制协议头为 http(s)://