越權漏洞,從原來的修改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