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