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

ivi

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

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

　　　　demo1.php:

1. <?php
   
2.     $a =$_GET['a'];
   
3.     if($a==1){
   
4.         echo 1;
   
5.     }else{
   
6.         echo "false";
   
7.     }
   
8. ?>

复制代码

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

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

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

1. %09        
   
2. %0a        
   
3. %0b        
   
4. %0c        
   
5. %0d        
   
6. %20        
   
7. %2b        
   
8. %30
   

复制代码

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

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

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

　　　当我自定义输入1aaa:

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

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

　　　　修改代码:

1. <?php
   
2.     $a =$_GET['a'];
   
3.     if($a===1){
   
4.         echo 1;
   
5.     }else{
   
6.         echo "false";
   
7.     }
   
8. ?>

复制代码

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

　　直接false.

　　java下的处理:

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

　　　　测试demo:

1.     @ResponseBody
   
2.     @GetMapping("/PathOne")
   
3.     public void PathOne(@RequestParam("url") int url,HttpServletResponse response) throws IOException {
   
4.         if(url==1){
   
5.             response.getWriter().write("1");
   
6.         }else{
   
7.             response.getWriter().write("false,fasle");
   
8.         }
   
9.     }

复制代码

　　和上面的测试一样

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

发现

1. 10    %09    200    false    false    93   
   
2. 11    %0a    200    false    false    93   
   
3. 12    %0b    200    false    false    93   
   
4. 13    %0c    200    false    false    93   
   
5. 14    %0d    200    false    false    93   
   
6. 29    %1c    200    false    false    93   
   
7. 30    %1d    200    false    false    93   
   
8. 31    %1e    200    false    false    93   
   
9. 32    %1f    200    false    false    93   
   
10. 33    %20    200    false    false    93   
    
11. 36    %23    200    false    false    93   
    
12. 44    %2b    200    false    false    93

复制代码

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

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

　　没有php那么多:　　

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

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

1. 10    %09    200    false    false    93   
   
2. 11    %0a    200    false    false    93   
   
3. 12    %0b    200    false    false    93   
   
4. 13    %0c    200    false    false    93   
   
5. 14    %0d    200    false    false    93   
   
6. 29    %1c    200    false    false    93   
   
7. 30    %1d    200    false    false    93   
   
8. 31    %1e    200    false    false    93   
   
9. 32    %1f    200    false    false    93   
   
10. 33    %20    200    false    false    93

复制代码

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

　　修改代码:

1.     @GetMapping("/PathOne")
   
2.     public void PathOne(@RequestParam("url") String url,HttpServletResponse response) throws IOException {
   
3.         if(url.equals("1")){
   
4.             response.getWriter().write("1");
   
5.         }else{
   
6.             response.getWriter().write("false,fasle");
   
7.         }
   
8.     }

复制代码

　　再次访问:

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

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

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

　　example:　　　　

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

福利视频

笔者自己录制的一套php视频教程(适合0基础的),感兴趣的童鞋可以看看,基础视频总共约200多集,目前已经录制完毕,后续还有更多视频出品

https://space.bilibili.com/177546377/channel/seriesdetail?sid=2949374

技术交流

[color=rgba(0, 0, 0, 0.9)]技术交流请加笔者微信:richardo1o1 (暗号:growing)

[color=rgba(0, 0, 0, 0.9)]如果你是一个长期主义者，欢迎加入我的知识星球([color=var(--weui-LINK)]优先查看这个链接，里面可能还有优惠券)，我们一起往前走，每日都会更新，精细化运营，微信识别二维码付费即可加入，如不满意，72 小时内可在 App 内无条件自助退款