参数未校验导致的DOS（服务拒绝）问题典型场景

前言

接口入参未做合法性校验/边界校验/大小限制 是后端高频高危漏洞，攻击者可通过构造恶意请求，利用业务逻辑缺陷直接耗尽服务器「CPU、内存、磁盘IO、网络带宽、数据库连接池」等核心资源，最终导致服务响应缓慢、卡死甚至完全不可用（DOS：Denial of Service 服务拒绝），所有场景均基于SpringBoot接口参数未校验的业务场景，覆盖常见、高发的类型。

---

一、【最高频】集合/数组参数无长度校验 → 内存耗尽型DOS

核心场景

接口接收 List、数组、Set 等集合类入参，未校验集合元素数量上限 ，如分页查询传size=1000000、批量操作传ids=[1,2,3,...10万+元素]、导入接口传无限制List数据。

触发原理

参数未校验 → 接收超大容量集合 → 服务端一次性加载海量数据到JVM内存 → 内存占用飙升触发GC频繁/Full GC → 内存溢出（OOM）→ 服务进程崩溃。

典型接口示例（SpringBoot）

// 未校验：ids集合无长度限制，攻击者传100万+ID
@PostMapping("/batch/getUser")
public Result batchGetUser(@RequestBody List<Long> ids) {
    return userService.batchQueryByIds(ids);
}

// 未校验：分页size无上限，攻击者传 size=500000
@GetMapping("/page/list")
public Result pageList(@RequestParam Integer pageNum, @RequestParam Integer size) {
    return goodsService.pageQuery(pageNum, size);
}

危害程度

⭐⭐⭐⭐⭐ 最高频、最易触发、危害最大，几乎所有项目都存在该隐患。

---

二、字符串参数无长度校验 → 内存/CPU双耗尽型DOS

核心场景

接口接收 String 类型入参（如搜索关键词、备注、内容、编码值等），未限制字符串字节/字符长度，攻击者传入超长字符串（如100万字符的文本）。

触发原理

1. 超长字符串加载到内存，直接占用大量堆内存，挤占正常业务内存空间；

2. 若业务中包含「字符串截取、正则匹配、JSON序列化/反序列化、加密解密、模糊查询」等操作，超长字符串会导致CPU满载运算，单请求耗时从毫秒级变为秒级；

3. 多并发下，大量慢请求堆积 → 线程池耗尽 → 新请求无法处理。

典型接口示例

// 未校验：keyword无长度限制，攻击者传100万字符的字符串
@GetMapping("/search")
public Result search(@RequestParam String keyword) {
    // 业务含模糊查询+字符串处理，直接拉满CPU
    return searchService.queryByKeyword(keyword);
}

// 未校验：content无长度限制，超大文本导致JSON解析耗时+内存溢出
@PostMapping("/save/note")
public Result saveNote(@RequestBody String content) {
    return noteService.save(content);
}

---

三、数值型参数无边界校验 → 业务逻辑异常导致的资源耗尽DOS

核心场景

接收 Integer/Long/Double 等数值型入参（如页码、条数、ID、循环次数、时间范围、金额等），未校验数值的合法边界/合理性，常见两种情况：

✅ 场景1：数值超限/非法值（最常见）

• 分页参数传 pageNum=-1、size=0、size=999999；

• ID参数传 0、-100、999999999999999；

• 时间戳传 0、9999999999999（超大时间），导致查询全量历史数据。

✅ 场景2：数值作为循环次数

参数直接作为业务循环的次数，如for(int i=0;i<count;i++)，攻击者传count=1000000，触发无限循环/超大循环，单请求直接耗尽CPU核心。

触发原理

数值非法/超限 → 业务逻辑执行异常（如查询全量表、执行超大循环、生成海量数据）→ 单请求占用核心资源超久 → 并发下服务彻底卡死。

典型接口示例

// 未校验：count无上限，传100万触发超大循环，CPU直接打满
@GetMapping("/generate/data")
public Result generateData(@RequestParam Integer count) {
    List<Data> list = new ArrayList<>();
    for (int i = 0; i < count; i++) { // 无校验的致命循环
        list.add(new Data(i));
    }
    return Result.success(list);
}

// 未校验：start/end时间无边界，传0和超大时间戳，查询全量数据→数据库+内存耗尽
@GetMapping("/query/byTime")
public Result queryByTime(@RequestParam Long startTime, @RequestParam Long endTime) {
    return orderService.queryByTime(startTime, endTime);
}

---

四、文件上传参数未校验 → 磁盘/内存耗尽型DOS（含批量上传）

核心场景

文件上传接口，未做任何校验 或 校验不全，是后端文件上传的必现漏洞，包含4类未校验点：

1. 未校验文件大小：上传超大文件（如10G视频、压缩包）；

2. 未校验文件数量：批量上传接口传成百上千个小文件；

3. 未校验文件类型：攻击者上传恶意大文件（即使无用，也纯占资源）；

4. 未校验文件后缀/内容：衍生漏洞，同时存在DOS风险。

触发原理

1. 超大文件/海量小文件直接占满服务器磁盘空间，导致后续文件写入失败、日志无法打印，服务直接不可用；

2. 文件上传时，服务端会先将文件加载到内存缓冲区，超大文件瞬间耗尽内存；

3. 无并发限制的上传接口，多攻击者同时上传 → 磁盘IO、网络带宽双满载。

典型接口示例

// 完全未校验：无大小、无数量、无类型限制，高危中的高危
@PostMapping("/upload")
public Result upload(@RequestParam MultipartFile file) {
    fileService.upload(file);
    return Result.success();
}

// 批量上传未校验数量：攻击者传1000个文件，瞬间占满磁盘
@PostMapping("/batch/upload")
public Result batchUpload(@RequestParam MultipartFile[] files) {
    fileService.batchUpload(files);
    return Result.success();
}

---

五、嵌套对象/JSON参数未校验 → 深层嵌套耗尽CPU+内存

核心场景

接口接收复杂嵌套的JSON对象/自定义实体类 入参（如多层级的查询条件、表单数据、业务对象），未校验对象的嵌套深度、子对象数量、子属性长度。

触发原理

SpringBoot默认使用Jackson/Gson解析JSON，无限深层嵌套的JSON 会让解析器递归解析，瞬间耗尽CPU；同时，多层级的对象会在内存中生成海量对象实例，触发内存溢出。

典型场景

攻击者构造如下恶意JSON请求体，发送给未校验的接口：

{
  "name": "恶意嵌套",
  "children": {
    "name": "嵌套1",
    "children": {
      "name": "嵌套2",
      "children": { ... } // 无限嵌套1000层+
    }
  }
}

危害特点

隐蔽性高，常规参数校验容易忽略「嵌套层级」这个维度，一旦触发，服务端JSON解析线程直接卡死，恢复难度大。

---

六、分页/查询类参数未校验 → 数据库级联DOS（最致命，连锁反应）

核心场景

属于「数值参数+集合参数」的组合高危场景，分页参数（pageNum/size）、查询条件参数 未做校验，是最容易引发生产事故的DOS场景，无任何例外！

触发原理（连锁反应，一环扣一环，不可逆）

参数未校验 → 执行超大分页/无限制查询 → 数据库压力过载 → 服务端卡死 → 全链路不可用

1. 攻击者传 size=100000，接口执行 select * from table limit 100000 → 数据库全表扫描，单SQL耗时秒级；

2. 数据库连接池被慢SQL占满，新请求拿不到连接 → 服务端接口超时堆积；

3. 数据库CPU/内存飙升，数据库服务卡死 → 依赖该数据库的所有微服务全部不可用；

4. 即使停掉攻击请求，数据库的慢SQL仍会执行很久，恢复时间长。

典型高危接口

// 未校验size，传100000 → 数据库直接崩掉
@GetMapping("/goods/list")
public Result goodsList(@RequestParam Integer size) {
    // mybatis执行 select * from goods limit #{size}
    return goodsMapper.selectList(size);
}

关键补充

该场景的危害远大于纯服务端DOS，因为数据库是核心共享资源，一旦数据库宕机，影响的是整个业务系统，而非单个接口/服务。

---

七、重复请求/并发参数未校验 → 资源重复占用型DOS

核心场景

接口接收「业务唯一标识参数」（如订单号、流水号、任务ID），未校验参数的唯一性/业务状态 ，同时未做幂等处理 ，攻击者利用该漏洞高频重复调用接口。

触发原理

1. 无参数唯一性校验 → 重复请求执行相同业务逻辑（如重复生成订单、重复发起支付、重复执行任务）；

2. 业务逻辑中会频繁操作数据库（插入、更新、锁表）、调用第三方接口、生成文件 → 数据库连接池、线程池、第三方接口配额被快速耗尽；

3. 最终导致正常请求无法执行，业务逻辑混乱+服务资源耗尽双重问题。

典型场景

支付回调接口、订单提交接口、任务执行接口、短信发送接口等核心业务接口。

---

八、特殊参数未校验 → 调用链/依赖服务级联DOS

核心场景

接口参数作为「下游服务调用的入参、中间件查询条件」，未做校验 ，攻击者构造恶意参数，导致「本服务没事，但下游服务/中间件被打崩」，最终级联反馈导致本服务不可用。

典型子场景

1. 参数作为Redis的keys查询条件，传*或超长key → Redis执行全库扫描，Redis服务卡死 → 依赖Redis的接口全部超时；

2. 参数作为MQ消息体，传超大/非法参数 → MQ消息堆积、消费失败 → MQ服务压力过载 → 消息生产/消费链路堵塞；

3. 参数作为调用第三方接口的入参，传非法值 → 第三方接口返回异常/超时 → 本服务线程池被阻塞调用占满；

核心特点

溯源难、危害范围广，属于「间接DOS」，但实际生产中发生概率极高，且排查难度大。

---

补充：参数未校验导致DOS的共性特点

✅ 所有场景的核心根因

入参「无校验、无限制、无边界」 ，本质是信任了前端传入的所有参数，未做服务端的「最后一道防线」校验。

✅ 高危接口共性特征

1. 接收 List、数组 等集合类型入参的接口；

2. 分页查询接口（含pageNum、size参数）；

3. 文件上传/批量上传接口；

4. 接收超长文本的搜索、备注、导入接口；

5. 数据库查询类高频接口；

6. 嵌套JSON对象入参的复杂接口。

---

免责声明：本文提及的所有工具方法仅用于安全学习和合法授权的测试活动，请勿用于任何非法用途。