url参数接收的一些安全应用场景

　　 越权漏洞,从原来的修改id越权到后面的自己加参数,减参数越权,到现在的加特殊字符.攻击手段在进步:

　　 以php和java为例,聊聊参数接收的最大接受能力,可以插入哪些脏数据?

　　　　demo1.php:

<?php
    $a =$_GET['a'];
    if($a==1){
        echo 1;
    }else{
        echo "false";
    }
?>

　　直接接收1参数,输出1,没啥问题:　　

　　测试环节1:在参数value前面加点东西跑下:

　　

在参数value的前面加入一些url编码数据,发现

%09        
%0a        
%0b        
%0c        
%0d        
%20        
%2b        
%30

　在数据前缀,加入这些url编码,不影响我们输出数据:

　测试环节2:在参数value后面加入一些url编码数据:

　　　　　

　　发现可控我们选择的数据有很多,长度203的就是符合条件的,都是返回1的:

　　　　

　　　当我自定义输入1aaa:

　　　　

　　仍然输出1,因为php中使用==匹配的是数字的时候,是自动帮你int,类似于intval操作.

 　　 修复这个问题的办法有很多,其中一种修复方案是:

　　　　修改代码:

<?php
    $a =$_GET['a'];
    if($a===1){
        echo 1;
    }else{
        echo "false";
    }
?>

　　再次尝试在参数value前面/后面加点数据:

　　

　　直接false.

　　java下的处理:

　　　　以spring boot为例子,其他的均未测试:

　　　　测试demo:

    @ResponseBody
    @GetMapping("/PathOne")
    public void PathOne(@RequestParam("url") int url,HttpServletResponse response) throws IOException {
        if(url==1){
            response.getWriter().write("1");
        }else{
            response.getWriter().write("false,fasle");
        }
    }

　　和上面的测试一样

　　测试环节1:对url参数value前面数据测试:

　　

　　

发现

10    %09    200    false    false    93    
11    %0a    200    false    false    93    
12    %0b    200    false    false    93    
13    %0c    200    false    false    93    
14    %0d    200    false    false    93    
29    %1c    200    false    false    93    
30    %1d    200    false    false    93    
31    %1e    200    false    false    93    
32    %1f    200    false    false    93    
33    %20    200    false    false    93    
36    %23    200    false    false    93    
44    %2b    200    false    false    93    

　　加入这几种url编码数据不会影响我们的输出:

　　测试环节2:在url参数value后面加入url编码数据进测试:

　　没有php那么多:　　

　　

　　他的底层和php的处理不一样.

　　他可支持的url编码数据是:

10    %09    200    false    false    93    
11    %0a    200    false    false    93    
12    %0b    200    false    false    93    
13    %0c    200    false    false    93    
14    %0d    200    false    false    93    
29    %1c    200    false    false    93    
30    %1d    200    false    false    93    
31    %1e    200    false    false    93    
32    %1f    200    false    false    93    
33    %20    200    false    false    93    

　　他的修复方案也有很多种,其中一种修复方案:

　　修改代码:

  @ResponseBody
    @GetMapping("/PathOne")
    public void PathOne(@RequestParam("url") String url,HttpServletResponse response) throws IOException {
        if(url.equals("1")){
            response.getWriter().write("1");
        }else{
            response.getWriter().write("false,fasle");
        }
    }

　　再次访问:

　　

　　

　　再次添加url编码数据已经不能修改了.

　　刚和phpoop聊完这个问题后,下午无聊刷推特就看到了相关实战案例,估计白帽子是黑盒的:

　　实战案例应用场景,当提取参数value的时候,和业务交接的时候,可能会存在安全问题:

　　example:　　　　

　　越权失败,新增一些url编码:

　　

　　更多的应用场景:waf bypass....

　　实战案例应用场景参考:https://16521092.medium.com/some-ways-to-find-more-idor-da16c93954e5